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Abstract 


H  >  < 

This  objective  of  this  was  to  evaluate  the  use  of  hyper¬ 

text  technology  for  an  automated  office  reference  system.  A  secondary 
purpose,  because  of  the  relative  newness  of  hypertext  technology,  was  to 
provide  a  single  reference  document  which  describes  hypertext  and  the 
steps  needed  in  managing  or  developing  a  hypertext  product.  Individ¬ 
uals  unfamiliar  with  hypertext  technology  can  learn  how  to  apply  it  in 
an  office  environment. 

The  evaluation  consisted  of  two  phases,  a  literature  review  to 

discover  the  hypertext  supports  for  a  reference  system  and  a  prototype 

development  and  test  of  an  Economic  Analysis  reference  system.  The 

literature  review  Includes  a  review  of  hypertext  features,  advantages 

and  disadvantages,  applications  (including  government  use),  factors 

* 

affecting  usability,  and  legal  concerns.  The  prototype  development 
answered  questions  In  three  areas:  economic  analysis  information 
required,  hypertext  development  concerns,  and  applicability  of  hypertext 
to  the  office  environment.*^ 

The  developed  prototype  /"tested  using  a  questionnaire  answered  by 
60  graduate  students,  showed  that  hypertext  has  strong  applicability  for 
an  office  reference  system.  The  results  showed  the  reference  system  was 
easy  to  learn  and  use,  would  provide  quicker  and  easier  access  to 
information,  and  users  could  learn  more  than  through  the  current  paper 


reference  system. 
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USE  OF  HYPERTEXT  FOR  THE  DEVELOPMENT  OF 


AN  OFFICE  REFERENCE  SYSTEM  ON  ECONOMIC  ANALYSIS 

I.  Introduction 

This  chapter  provides  an  introduction  to  the  research.  First, 
problems  with  the  current  reference  system  for  economic  analysis  are 
discussed.  Second,  hypertext  is  described  as  it  will  be  used  for 
development  of  an  automated  reference  system  on  economic  analysis. 

Next,  the  specific  investigative  questions  which  this  research  answers 
are  presented.  Then  the  scope  and  limitations  of  this  research  are 
characterized.  Finally,  the  thesis  organization  is  outlined. 

General  Issue 

Today’s  office  -eference  system  for  economic  analysis  within  the 
Department  of  Defense  Is  manual — consisting  of  separate  paper  files, 
regulations,  guidebooks,  policy  letters,  correspondence,  training  course 
textbooks,  and  other  paper  documents.  The  reference  system  is  used  by 
individuals  with  varying  knowledge  levels,  from  those  first  learning 
economic  analysis  techniques  to  those  needing  to  research  the  answer  to 
specific  questions. 

The  Base  Level  Cost  Analysis  Handbook,  developed  for  the  Air  Force 
In  1988,  was  designed  to  become  a  concise  reference  system  for  base- 
level  cost  analysis  tasks.  As  such,  the  handbook  consists  of  two  books 
and  over  1,000  pages.  Two  chapters  deal  specifically  with  economic 
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analysis,  Chapters  8  and  11.  These  chapters  combined  are  nearly  200 
pages  long  and  use  many  cross  references  to  other  chapters  of  the 
handbook  (26).  Therefore  to  access  the  needed  information  on  economic 
analysis,  both  volumes  are  required.  Although  the  handbook  references 
over  30  mgulations  and  guides  specifically  pertaining  to  economic 
analysis  (26:11-8  to  11-10),  none  are  contained  in  it.  The  user  must 
access  needed  regulations  through  a  different  source,  either  within  her 
office  or  through  a  master  publications  library.  Each  base  level  cost 
analyst  is  provided  a  copy  of  the  handbook.  Economic  analysis  informa¬ 
tion  similar  to  the  above  handbook  is  also  presented  in  Volume  I  of  the 
AFSC  cost  estimating  handbook  series,  AFSC  Cost  Estimating  Handbook 
(25). 

Within  most  major  commands,  the  base  level  cost  office  within  the 
comptroller  organization  is  the  office  of  primary  responsibility  for 
economic  analysis.  The  cost  office  is  responsible  for  both  conducting 
the  economic  analysis  and  Identifying  offices  of  collateral  responsi¬ 
bility  to  help  formulate  alternatives,  make  assumptions,  and  provide 
needed  data  (23:5).  With  recent  budget  cutbacks  however,  a  proposal  is 
under  consideration  to  eliminate  or  greatly  reduce  base  level  cost 
analyst  positions,  thus  disbanding  the  current  pool  of  experience  for 
conducting  economic  analyses. 

Within  other  major  commands,  such  as  the  Air  Force  Communication 
Command,  there  are  no  base  level  cost  analysts;  responsibility  for 
accomplishing  economic  analyses  falls  to  Individuals  within  the 
functional  organizations.  These  individuals  typically  have  no  back¬ 
ground  training  or  knowledge  of  the  techniques  required  to  conduct 
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economic  analyses.  They  also  do  not  have  immediate  access  to  the 
handbooks  referenced  above  or  any  of  the  needed  regulations. 

Many  Department  of  Defense  agencies  provide  training  courses  or.  the 
techniques  used  in  conducting  economic  analyses:  Sheppard  Technical 
Training  Center  (STTC),  the  Air  Force  Institute  of  Technology  (AFIT), 
U.S.  Army  Logistics  Management  Center  (ALMC) ,  Army  Management  Engineer¬ 
ing  Training  Activity  (AMETA),  and  Defense  Systems  Management  College 
(DSMC).  Course  prerequisites  often  limit  the  Individuals  who  can  attend 
the  training  to  those  working  in  an  economic  or  cost  analyst  position, 
effectively  removing  the  functional  individual  from  consideration  for 
the  courses  (24:1).  Limited  quotas  are  available  for  many  of  the 
courses  taught  by  the  above  agencies,  meaning  that  individuals  respon¬ 
sible  for  conducting  economic  analyses  may  not  be  able  to  attend  the 
courses  when  needed.  Often,  one  Individual  from  each  office  attends  the 
courses  and  is  expected  to  train  the  remainder  of  her  office.  If  the 
individual  changes  jobs  before  the  in-office  training  can  be 
accomplished,  the  office  no  longer  has  access  to  the  needed  knowledge. 

The  above  conditions  combined  make  It  difficult  to  maintain 
adequate  reservoirs,  In  an  office  that  Is  required  to  conduct  economic 
analyses,  both  of  Individuals  trained  In  economic  analysis  techniques 
and  the  needed  economic  analysis  Information.  This  can  cause  delayed 
proficiency  gain  for  Inexperienced  workers,  lower  quality  economic 
analyses,  and  lost  continuity  with  Job  changes. 

The  need  for  a  more  concise  and  more  easily  delivered  package  on 
economic  analysis  is  Indicated  by  the  efforts  of  the  Air  Force  Cost 
Center;  they  are  working  on  development  of  microcomputer-based  training 
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modules  on  economic  analysis.  At  this  time,  they  have  developed  two 
computer  based  training  (CBT)  modules:  "How  to  Document  an  Economic 
Analysis"  and  "Time  Value  of  Money".  Another  module  due  to  be  released 
soon  is  on  economic  analysis  and  combines  the  documentation  CBT  with 
economic  analysis  overview  information  (22).  Appendix  A  provides  a 
description  of  each  of  the  CBT  modules. 

This  research  examines  another  method  of  improving  the  internal 
office  reference  system  through  automation — hypertext. 

Specific  Problem 

One  way  to  tie  separate  reference  documents  together  into  one 
concise  package  is  with  hypertext.  Hypertext  Is  a  type  of  computer 
database  system  that  supports  non- sequential ly  linked  pieces  of  text. 
"Rather  than  turning  pages  to  find  more  information  or  using  an  index  to 
find  a  topic,  it  [hypertext]  Is  structured  so  that  wherever  more 
Information  exists  It  is  linked  off  a  key  word  or  phrase”  (61:1). 
Hypertext  provides  for  machine  supported  links  to  cross  reference  or 
continuing  Information. 

The  setup  of  a  hypertext  application  works  in  several  steps. 

First,  the  existing  reference  documents  are  input  into  the  computer 
database  in  linear  form.  Next,  these  documents  are  broken  Into  blocks 
of  text  that  typically  express  a  single  idea.  Finally,  the  blocks  are 
linked  together  In  two  ways — linear  (as  originally  Input)  and  nonlinear. 
The  nonlinear  links  allow  reference  blocks  from  the  same  or  separate 
documents  to  be  linked  together,  providing  paths  through  the  database  on 
specific  subject  areas  (e.g.  inflation  factors).  The  user  of  a  hyper- 
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text  system  accesses  text  blocks  through  a  series  of  windows,  following 
a  network  of  linked  information. 

This  research  has  a  twofold  purpose.  First,  It  develops  a  proto¬ 
type  hypertext  economic  analysis  reference  system.  Hypertext  has 
already  been  used  on  projects  of  similar  scope  within  other  organiza¬ 
tions  as  discussed  in  the  literature  review.  Secondly,  because  of  the 
relative  newness  of  hypertext  technology  this  research  presents  a  single 
reference  which  describes  hypertext  and  the  steps  needed  in  managing  or 
developing  a  hypertext  product. 

Research  Questions 

Three  general  areas  of  research  questions  are  answered.  The  first 
deals  with  the  Information  needed  for  an  economic  analysis  reference 
system.  The  questions  are  as  follows: 

1.  What  economic  analysis  documents  are  necessary  to  give  a  good 
test  of  a  prototype  system? 

2.  Are  these  documents  available  in  computerized  form,  and  if  not, 
how  can  they  be  computerized? 

The  second  area  deals  with  the  hypertext  system  development.  The 
questions  answered  here  are: 

1.  What  hypertext  systems  are  available  or  obtainable  for  educa¬ 
tional  research? 

2.  What  computer  system  is  more  appropriate  (mainframe,  micro,  or 
mini)? 

3.  What  methodology  should  be  used  to  break  documents  into  text 
blocks? 

4.  What  nonlinear  links  are  needed? 
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The  third  area  deals  with  the  use  of  the  system  in  the  office 
environment.  The  specific  research  questions  are  as  follows: 

1.  Is  a  hypertext  system  compatible  with  office  reference, 
specifically,  does  linked  text  provide  easy  use  in  finding  and  learning 
information? 

2.  What  capabilities  are  available  to  update  the  hypertext 
references  as  new  regulations  or  references  become  available? 

Scope 

Due  to  the  substantial  number  of  references  available  on  economic 
analysis,  this  prototype  reference  system  deals  with  a  sample  that 
demonstrates  the  hypertext  capability  in  this  area.  Because  of  the  many 
references  already  available,  the  prototype  uses  existing  documents;  no 
new  text  Is  created.  Those  types  of  economic  analyses  that  are  typi¬ 
cally  performed  in  the  operational  environment  provide  the  basis  for  the 
selection  of  information.  Because  of  the  limited  depth  of  the  proto¬ 
type,  a  complete  analysis  of  user  requirements  was  not  accomplished. 

Because  the  prototype  was  used  to  demonstrate  the  concept  of  using 
hypertext  for  an  economic  analysis  office  reference  system,  prototype 
testing  was  not  as  extensive  as  for  an  actual  production  system. 
Prototype  development  usually  consists  of  iterative  development  and 
tests  of  a  product.  This  research  was  limited  to  iterative  development 
and  one  overall  prototype  test. 

Research  Development 

The  research  on  this  topic  follows  the  pattern  outlined  below. 
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Chapter  I  Introduces  the  research.  It  discusses  the  current 
problem  with  the  economic  analysis  reference  system,  a  possible  solution 
in  hypertext,  specific  research  questions,  and  the  scope  of  the  re¬ 
search. 

Chapter  II  contains  a  review  of  the  literature  applicable  to  the 
use  of  hypertext  as  a  reference  system. 

Chapter  III  discusses  the  methodology  to  be  used  in  developing  the 
prototype  reference  system. 

Chapter  IV  provides  the  findings  and  analysis  in  development  and 
testing  of  the  prototype. 

Chapter  V  presents  conclusions  reached  through  the  research  and 
recommends  areas  for  follow-on  research. 
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This  chapter  presents  a  review  of  the  literature  relevant  to  the 


development  of  a  hypertext  office  reference  system.  First,  a  brief 
history  of  hypertext  Is  reviewed.  Second,  an  overview  of  the  key 
features  of  a  hypertext  system  Is  presented.  A  discussion  of  the 
advantages  and  disadvantages  of  using  hypertext  for  accessing  large 
amounts  of  information  follows.  Next,  the  browsing  feature  is  examined 
In  more  detail.  Two  classification  schemes  are  then  provided  to  give 
the  reader  a  better  understanding  of  the  various  ways  hypertext  systems 
can  be  used  and  how  reference  systems  are  classified.  Several  specific 
applications  similar  to  this  thesis  project  are  discussed.  Government 
use  of  hypertext  applications  is  briefly  examined. 

Hypertext,  from  the  user’s  perspective,  is  discussed  in  terms  of 
factors  effecting  usability  of  hypertext  systems.  Legal  implications  of 
a  hypertext  document  are  then  discussed.  Finally,  the  chapter  concludes 
with  a  preview  of  the  future  for  hypertext. 

History  of  Hypertext 

Many  people  view  hypertext  as  being  a  recent  concept.  This  is  not 
true;  however.  It  is  only  recently  that  the  computer  technology  has  been 
available  to  support  the  concept.  Hypertext  was  first  described  in  1945 
by  Vannevar  Bush,  President  Roosevelt’s  Science  Advisor  In  an  article 
for  the  Atlantic  Monthly  called  "As  We  May  Think"  (14).  Bush  proposed  a 
"memex"  machine  based  upon  microfilm  and  photocells  and  described  the 
machine’s  essential  feature  as  the  ability  to  tie  two  items  together. 
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Although  the  memex  was  never  developed.  Bush  is  given  credit  for  the 
original  thought  of  machine  supported  linking  of  information  (18:10). 

Additional  work  in  the  area  was  not  performed  until  nearly  20  years 
later  when  Douglas  Engelbart  and  Ted  Nelson  began  work  on  H-LAM/T  (Human 
using  Language,  Artifacts,  and  Methodology,  in  which  he  is  Trained)  and 
Xanadu  respectively.  Guide,  the  first  hypertext  system  for  personal 
computers  was  released  in  1985  (74:88-89).  A  detailed  history  of 
hypertext  systems  is  presented  in  A  Survey  of  Hypertext  (18:7-37)  and 
Hypertext  Hands-On!  (74:75-94). 


Standard  Hypertext  Features 

Manual  Hypertext  Systems.  Although  the  computer  technology 
supporting  hypertext  is  new,  manual  equivalent  systems  have  existed  for 
a  long  time. 

One  example  is  the  encyclopedia.  As  you  read  an  article  in  an 
encyclopedia,  you  find  references  to  related  items  which  will 
have  more  Information.  These  references  are  usually  "non¬ 
linear";  that  is,  the  other  items  or  articles  do  not  generally 
directly  follow  the  one  you  are  looking  at.  You  may  have  to 
open  another  volume  In  the  set.  You  may  also  be  referred  to  a 
diagram  or  picture  elsewhere  in  the  encyclopedia.  (42) 

An  encyclopedia  set  can  be  considered  one  large  document  with  many 
interrelated  articles.  If  the  encyclopedia  were  automated  with  hyper¬ 
text  It  would  be  a  hyperdocument,  with  all  Inter-article  and  Intra¬ 
article  relationships  specifically  computer  supported  with  links. 

Building  Blocks.  The  key  feature  of  a  hypertext  system  consists  of 
machine  supported  links  for  connecting  information  within  a  nonlinear 
database  (18:3;  31:237;  21:169;  59:27).  In  addition  to  th’s  key 
ingredient,  two  other  essential  features  characterize  hypertext  systems. 
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First,  information  is  broken  into  "chunks"  or  nodes  that  typically 
express  a  single  idea  or  concept.  While  a  hypertext  system  is  limited 
to  text  information,  a  hypermedia  system  may  Include  other  elements  such 
as  graphics,  video,  audio,  still  pictures,  and  animation. 

Second,  users  browse  through  information  within  a  hypermedia 
database  by  following  links  from  node  to  node.  The  entire  system  forms 
a  hyperdocument  network  in  which  all  the  nodes  are  connected  by  links 
(18:6;  76:33;  1:820;  59:27). 

Figure  1  displays  a  window  with  links  and  the  action  that  occurs 
when  one  link  Is  activated. 

The  next  portion  of  this  section  further  explains  these  building 
blocks  and  provides  additional  information  on  the  average  current  hyper¬ 
text  system. 

Links.  "Links  are  the  labels  that  connect  one  node  (document, 
article,  topic)  with  another"  (74:3).  They  must  have  the  ability  to 
rapidly  transport  the  user  to  new  places  within  the  hyperdocument,  as 
the  decision  to  follow  a  link  "Is  associated  with  a  cost  (e.g.,  time, 
distraction,  annoyance)  and  a  reward  (e.g.,  useful  information)” 
(34:882).  Akscyn  feels  that  the  ability  to  rapidly  traverse  a  link  is 
the  "most  Important  parameter  of  a  hypermedia  system"  (1:829).  Conklin 
states  that  a  delay  of  one  or  two  seconds  is  unacceptable  (18:39)  and 
Akscyn’s  design  goal  Is  a  response  time  of  less  than  0.25  seconds 
(1:829). 

Links  have  two  ends,  the  link  source  (reference)  and  the  link 
destination  (referent)  (18:41;  31:239).  The  method  of  indicating  source 
and  destination  within  the  hyperdocument  varies  by  system.  Among  the 
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Figure  1.  Hypertext  Window  With  and  Without  Link  Activation 


ways  used  to  indicate  links  are:  boxed  text  (39:837),  icons  (76:35), 
reverse  video,  fonts,  color  (18:41),  and  whole  text  (1:829).  Regardless 
of  the  Indication  method,  only  one  or  two  keystrokes  or  taps  of  a  mouse 
button  should  be  needed  to  activate  the  link  (31:239;  18:39;  39:837). 

Links  can  be  used  for  a  variety  of  purposes.  They  can: 

-  transfer  to  a  new  topic 

-  show  a  reference  (or  go  from  a  reference  to  the  article) 

-  provide  ancillary  information,  such  as  a  footnote,  defini¬ 
tion,  or  annotation 

-  display  an  illustration,  schematic,  photograph,  or  video 

sequence 

-  display  an  index 

-  run  another  program  (e.g.,  a  spreadsheet  or  animation)  (74:4) 

Some  systems  allow  creation  of  link  types  to  indicate  link  purpose, 
with  the  number  of  typed  links  varying  greatly  by  system,  from  over 
eighty  (18:15)  to  two  (1:828).  These  types  are  used  to  define  the 
specific  relationships  between  information  being  linked,  e.g.,  citation, 
background,  solution,  correction,  methodology,  rewrite,  argument 
(18:14),  referential,  and  organizational  (parent-child)  (18:43).  Other 
properties  of  links  in  hypertext  documents  include:  creation,  deletion, 
editing,  naming,  listing,  and  directing  (18:40;  31:239). 

Nodes .  Nodes  and  the  links  that  connect  them  form  a  nonlinear 
network.  Nodes  also  have  varying  characteristics  depending  upon  the 
hypertext  system.  While  a  node  typically  expresses  one  Idea,  a  system’s 
node  length  varies  from  screen  size  (1:827)  to  whole  books  (18:48).  The 
variance  In  node  size  Is  based  on  how  the  information  Is  presented; 
article-based  or  card-based.  Article-based  systems  present  entire 
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documents  in  one  node,  allowing  the  user  to  scroll  through  the  text 
onscreen.  A  disadvantage  here  would  be  loss  of  information  if  the  user 
did  not  know  to  scroll  down  for  more  information.  Card-based  systems 
limit  node  size  to  the  size  of  the  screen  and  are  nonscrolling.  Card- 
based  systems  eliminate  the  problem  of  scrolling,  but  information  needs 
to  be  broken  into  screen  size  chunks,  thus  increasing  the  conversion 
time  from  linear  text  to  hyperdocument  (61:5-6). 

Regardless  of  the  type  of  system,  node  units  should  be  such  that: 

a)  an  individual  idea  can  be  referenced  elsewhere  .  .  .  and 

b)  alternative  successors  of  a  unit  can  be  offered  to  a  reader 
(e.g.,  more  detail,  an  example,  bibliographic  references,  or 
the  logical  successor).  (18:48) 

Small  nodes  allow  greater  organizational  possibilities  while  large  nodes 
minimize  the  time  and  complexity  of  traversing  between  nodes  (18:49). 

Nodes  can  contain  varying  information  depending  upon  the  system. 

In  a  hypertext  system,  node  content  is  limited  to  text.  In  a  hypermedia 
system  content  is  limited  only  by  what  the  current  technology  can 
provide  (76:33).  Some  systems  allow  nodes  to  be  viewed  as  composites 
where  related  subnodes  can  be  viewed  together  or  individually  (18:52; 
31:239).  Nodes  can  also  be  typed,  similar  to  the  typing  of  links,  to 
specify  the  information  contained  (18:50). 

Browsing.  When  hypertext  was  originally  thought  of  by  Bush  in  1945 

it  was  on  the  principle  of  browsing. 

The  human  mind  .  .  .  operates  by  association.  With  one  item  in 
its  grasp,  It  snaps  Instantly  to  the  next  that  is  suggested  by 
the  association  of  thoughts,  in  accordance  with  some  intricate 
web  of  trails  carried  by  the  cells  of  the  brain.  (14:106) 

Browsing  within  a  hyperdocument  may  take  place  in  three  ways: 
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a)  by  following  links  and  opening  windows  successively,  ex¬ 
amining  their  contents, 

b)  by  searching  the  network  (or  part  of  it)  for  some  string, 
keyword,  or  attribute  value,  and 

c)  by  navigating  around  the  hyperdocument  using  a  specialized 
graphical  browser  that  displays  the  network  (e.g.  with  nodes 
displayed  as  icons  and  links  as  lines  between  them.  (18:7) 

Figure  2  displays  a  graphical  browser  from  the  HyperWrlter  (TM) 
hypertext  software.  The  nodes  are  identified  both  by  window  name  and 
window  number  with  lines  indicating  the  link  structure  between  them.  At 
the  bottom  left  of  the  map  window  the  top  part  of  the  indicated  node  is 
displayed. 


table  of  contents  Ins  L  1  C : Hi 
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Average  Current  System.  As  discussed  above,  the  key  features  of 


hypertext  (links,  nodes,  and  browsing)  vary  between  systems.  The 
average  current  hypertext  system,  however,  has  the  features  shown  in 
Table  1. 

TABLE  1 

Features  of  a  Hypertext  System  (39:840) 


Feature 


Description 


Nodes: 

Links: 


Overview: 

Hierarchies: 
User  Interface: 
Search/query: 
Storage: 


Typed  (text,  graphics  .  .  .),  implemented  using 
a  type  hierarchy 

Binary,  bidirectional;  labeled  but  not  typed. 
Anchors  can  be  whole  nodes  or  points/ regions 
within  the  node 

Browsers  containing  node/1  ink  diagrams  of  the 
network 

Special  support  for  hierarchical  networks 

Multiple  windows;  mouse/menu  driven 

Slow,  full-text  string  match 

Standard  files  or  relational  DBMS  [Data  Base 

Management  System] 


As  with  any  computer  software  technology,  hypertext  has  certain 
advantages  and  disadvantages  for  use  in  specific  applications.  The  next 
section  considers  advantages  and  disadvantages  of  using  a  current 
hypertext  system  for  reading  and  structuring  of  information. 


Hypertext  Advantages  and  Disadvantages 

Advantages.  Conklin  describes  many  advantages  in  the  use  of 
hypertext  for  accessing  large  amounts  of  information. 

1.  ease  of  tracing  references:  machine  support  for  link 
tracing  means  that  all  references  are  equally  easy  to  follow  to 
their  referent,  or  backwards  to  their  reference; 

2.  ease  of  creating  new  references:  users  can  grow  their  own 
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networks,  or  simply  annotate  someone  else’s  document  with  a 
comment  (without  changing  the  reference  document); 

3.  information  structuring:  both  hierarchical  and  non-hier- 
archical  organizations  can  be  imposed  on  unstructured  informa¬ 
tion;  even  multiple  hierarchies  can  organize  the  same  mater¬ 
ial  ; 


4.  global  views:  browsers  provide  table-of-contents  style 
views,  supporting  easier  restructuring  of  large  or  complex 
documents;  global  and  local  views  can  be  mixed  effectively; 

5.  customized  documents:  text  segments  may  be  threaded  to¬ 
gether  in  many  ways,  allowing  the  same  document  to  serve  mul¬ 
tiple  functions; 

6.  modularity  of  Information:  since  the  same  text  segment  can 
be  referenced  from  several  places,  ideas  can  be  expressed  more 
modularly,  i.e.  with  less  overlap  and  duplication; 

7.  consistency  of  information:  references  are  imbedded  in 
their  text — if  the  text  is  moved,  even  to  another  document,  the 
link  information  still  provides  direct  access  to  the  reference; 

8.  task  stacking:  the  user  is  supported  in  having  several 
paths  of  Inquiry  active  and  displayed  on  the  screen  at  the  same 
time,  such  that  any  given  path  can  be  unwound  to  the  original 
task; 

9.  collaboration:  several  authors  may  collaborate,  with  the 
document  and  comments  about  the  document  being  tightly  inter¬ 
woven  (this  feature  Is  just  beginning  to  be  explored),  [num¬ 
bers  added]  (18:56) 

Disadvantages.  Conklin  goes  on  to  describe  two  classes  of  problems 
with  hypertext,  implementation  problems  and  problems  endemic  to  hyper¬ 
text.  The  Implementation  problems  vary  from  system  to  system  and 
Include,  "delays  In  display  of  referenced  material,  restrictions  on 
names  and  other  properties  of  links,  lack  of  or  deficiencies  in  brow¬ 
sers,  paucity  of  .  .  .  powerful  specialized  "views"  of  networks  .  .  . 
(18:56). 

Two  problems  are  endemic  to  hypertext  systems,  disorientation  and 
cognitive  overhead.  Disorientation  is  caused  by  the  great  number  of 
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dimensions  through  which  a  reader  can  move.  Conklin  cites  two  solu¬ 
tions,  "graphical  browsers  and  query/search  mechanisms"  (18:56-57). 
Cognitive  overhead  is  related  to  the  mental  “overhead  of  meta-level 
decision  making"  of  which  link/path  to  follow.  The  user  has  to  decide 
if  a  specific  link  is  worthwhile  to  follow.  This  problem  is  eased 
through: 

having  the  cross  referenced  node  appear  very  rapidly  .... 
providing  an  instantaneous  one  to  three  line  explanation  of  the 
side  reference  in  a  pop  up  window  .  .  and  having  a  graphical 
browser  which  shows  the  local  subnetwork  into  which  the  link 
leads.  (18:59-60) 

Other  authors  confirm  the  problems  of  disorientation  and  excess  overhead 
in  hypertext  (1:831;  18:56-59;  6:261;  39:841-845;  81:398). 

Both  implementation  and  endemic  problems  are  related  to  the  area  of 
browsing  to  find  information  in  a  hyperdocument.  Because  of  the  sig¬ 
nificance  of  the  browsing  problem,  the  next  section  concentrates  on 
techniques  that  hypertext  systems  use  to  reduce  disorientation  while 
browsing. 

Orientation  Techniques 

The  worst  effects  of  disorientation  can  be  remedied  by  orientation 
tools  that  are  prominent,  ever  present,  and  predictable  (7:43).  The 
following  tools  work  together  in  various  hypertext  systems  to  provide 
the  user  with  orientation  cues. 

Graphical  Browsers.  The  most  common  method  of  browsing  a  hypertext 
system  Is  through  a  graphical  browser  (see  Figure  1).  This  browser 
displays  the  structure  of  the  hyperdocument  as  graphs  which  provide 
contextual  and  spatial  cues  to  the  user  about  the  nodes  he  is  viewing 
and  how  they  are  linked  to  each  other  (18:7).  A  browser  may  be  global 
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or  local.  In  the  global  mode,  it  displays  all  links  available  in  the 
system.  While  in  the  local  mode,  only  those  links  that  emanate  from  the 
current  node  are  shown  (76:39).  A  global  map  is  helpful  for  small 
hyperdocuments,  but  as  networks  become  large  (over  50  links)  global  maps 
"become  quite  overwhelming"  (76:39-40). 

Some  systems  display  this  network  permanently  on  part  of  the  screen 
(6:256)  and  others  allow  it  to  be  brought  up  as  an  individual  node 
(39:837).  Systems  may  automatically  compute  the  graphical  browser 
(39:837),  require  the  author  of  the  hyperdocument  to  create  them  (7:39), 
or  not  provide  them  (1:830). 

Certain  factors  combine,  however,  to  make  It  impossible  to 
alleviate  the  disorientation  problem  with  a  browser  alone: 

a)  large  number  of  nodes, 

b)  large  number  of  links, 

c)  frequent  changes  in  network, 

d)  slow  or  awkward  response  to  user  control  inputs, 

e)  insufficient  visual  differentiation  among  nodes  and/or 

links,  and 

f)  non-visual ly  oriented  users  .  .  .  (18:57) 

Because  of  this  many  hypertext  designers  have  added  additional  orienta¬ 
tion  tools  to  their  systems. 

Bookmark.  Bookmarks  allow  the  reader  to  mark  or  unmark  pages  as 
they  navigate  a  hyperdocument.  If  they  get  lost  within  the  document, 
they  can  easily  flip  back  to  a  page  they  have  marked  (7:39-40). 

Filters.  These  are  typically  used  to  mask  the  detail  of  a  network  so 
that  the  user  is  presented  with  a  manageable  level  of  complexity.  They 
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often  provide  a  capability  for  the  user  to  shift  the  level  of  complexity 
as  desired  (18:57,  83:71,76). 

Guided  Tour.  This  concept  is  present  in  many  hypertext  systems, 
although  by  different  names:  trails,  paths,  active  path  (81:400),  tour, 
and  guide  (83:65).  Guided  tours  provide  an  ordered  list  of  nodes  to 
follow  which  allow  the  user  to  "read  the  material  in  the  suggested  order 
as  if  it  were  a  linear  document"  (18:15). 

Indexing.  Two  methods  of  Indexing  can  be  used,  alphabetical  and 
hierarchical .  Indexing  allows  the  user  to  look  up  an  alphabetized  list 
of  topics  and  key  words  Included  In  the  hyperdocument.  A  hierarchical 
index  provides  a  table  of  contents  that  displays  the  overall  structure 
of  the  hyperdocument  (74:11-12). 

Path  History.  This  feature  provides  reversibility  by  maintaining 
and  displaying  a  list  of  previously  reviewed  nodes.  A  user  can  quickly 
jump  back  to  any  of  these  nodes  by  activating  the  link  within  the  path 
history  (74:15).  Some  systems  automatically  record  the  path  followed  so 
tha"  he  user  can  backtrack  at  any  time  (1:830).  A  related  concept  is 
the  use  of  "breadcrumbs".  A  small  marker  is  displayed  in  a  node  to  show 
the  user  they  have  already  seen  the  material.  These  crumbs  allow  the 
user  to  call  up  a  list  of  recently  visited  pages  at  any  time  and  to  jump 
to  any  such  page.  The  system  limits  the  length  of  the  list  to  avoid 
disorientating  the  user  with  a  large  menu.  "Thus,  crumbs  represent 
pages  .  .  .  read  recently,  and  Imaginary  birds  remove  breadcrumbs  the 
reader  leaves  unvisited  for  more  than  thirty  pages”  (7:42-43). 

Search  and  Query.  Two  methods  are  used  for  search  and  query, 
content  search  and  structure  search  (39:842).  The  content  search 
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examines  all  links  and  nodes  Independently  to  locate  a  match  for  a 
keyword  or  string  (31:240).  A  structure  search  looks  at  the  hyperdocu¬ 
ment  structure  to  match  a  given  pattern  (6:262).  Desirable  features  in 
a  search  function  Include  the  ability  to  specify  "case-sensitivity 
(l.e. ,  whether  to  ignore  upper/lower  case),  boolean  expressions  (terms 
combined  with  AND,  OR,  NOT),  and  "wild  card”  characters  that  do  not  have 
to  be  matched"  (74:12). 

Tabletops.  Again,  these  are  described  by  several  different  names 
depending  upon  the  hypertext  system:  fileboxes  (39:838),  composites 
(6:258),  webs  (18:29),  collections  (18:31),  and  stacks  (18:32). 

Tabletops  compile  related  nodes  into  one  group  which  can  be  saved, 
edited,  and  recalled  as  a  group  at  any  time  (81:402-403). 

Hypertext  Classifications 

Halasz’  method  for  classifying  hypertext  systems  (as  described  by 
Nielsen)  specifies  four  dimensions  as  shown  in  Table  2.  This  classifi¬ 
cation  scheme  allows  identification  of  hypertext  systems  over  the  entire 
scope  of  hypertext  development  and  use.  It  can  be  used  to  give  an 
overall  picture  of  any  hypertext  system. 

Conklin,  on  the  other  hand,  classifies  hypertext  systems  as  shown 
in  Table  3.  The  scheme  in  Table  3  is  a  combination  and  further  clarifi¬ 
cation  of  two  categories  in  Table  2,  scope  of  the  user  target  and 
browsing  versus  authoring. 

The  classification  in  Table  3  is  important  because  it  clearly 
identifies  the  end  purpose  of  a  hypertext  system.  The  reference  system 
proposed  in  this  thesis  is  categorized  as  a  browsing  system. 
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TABLE  2 


Hypertext  Classification  Scheme  1  (59:28) 


generation 

scope  of  the  user  target 

browsing  versus  authoring 

task  specificity 

original  (1945  to  1980)  and  cur¬ 
rent  (1980s) 

single  user,  work  group,  cor¬ 
porate  division,  and  the  whole 
world 

Information  presentation  versus 
network  creation  and  manipula¬ 
tion 

general,  some  task  specificity, 
and  task  specific 

TABLE  3 

Hypertext  Classification  Scheme  2  (18:9-10) 

macro  literary  systems 

.  .  .  large  on-line  libraries  . 

.  .  [for]  all  publishing,  read¬ 
ing,  collaboration,  and  criti¬ 
cism  .  .  .  within  the  network. 

problem  exploration  tools 

tools  to  support  early  unstruc¬ 
tured  thinking  on  a  problem,  In 
which  many  disconnected  ideas 
come  to  mind  .  .  . 

browsing  systems 

similar  to  macro  literary  sys¬ 
tems,  but  smaller  scale  -  sys¬ 
tems  for  teaching,  reference, 
and  public  Information,  where 
ease  of  use  is  crucial. 

general  hypertext  technology 

general  purpose  systems  designed 
to  allow  experimentation  with  a 
range  of  hypertext  applica¬ 
tions — most  commonly  applied  to 
reading,  writing,  collabora¬ 
tion,  etc.. 

Hypertext  Applications 

As  discussed  above,  hypertext  can  be  used  in  many  different  ways. 
Because  this  research  Is  centered  on  the  use  of  hypertext  for  an  office 
reference  system,  the  applications  described  below  are  primarily 
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browsing  systems,  systems  that  are  used  for  teaching  and  reference. 
Appendix  B  discusses  other  applications  that  are  possible  with  hyper¬ 
text.  Another  source  that  describes  many  applications  of  hypertext  is 
Hypertext  Hands-On!  (74:19-33,  107-115). 

Navy  Aircraft  Carrier  System.  The  USS  Carl  Vinson  uses  a  hyper¬ 
text  management  information  system  called  ZOG  ("which  stands  for 
nothing,  but  is  short,  easily  pronounced  and  easily  remembered" 

(68:461))  that  supports  four  online  applications:  Ship  Organization  and 
Regulation  Manual  (SORM),  Interactive  task  management  system,  technical 
manuals,  and  user  Interface  for  AlrPlan.  Each  application  is  described 
in  more  detail  below. 

The  SORM  is  designed  to  be  accessed  online  by  human  and  agent 
(application  programs)  users. 

Agents  use  the  SORM  to  support  interactive  task  management. 

Tasks  described  In  the  SORM  are  copied  and  their  generic  por¬ 
tions  are  Instantiated  to  reflect  the  particulars  at  hand 
(times,  people,  etc.).  These  specific  structures  are  then  used 
to  track  the  status  of  these  tasks  and  generate  reports  .  .  . 
(56:303) 

Technical  manuals  for  aircraft  and  weapons  elevators  are  supported 
online  and  Integrated  with  video  disk  material.  This  allows  a  video- 
disk  player  to  play  applicable  portions  of  the  disk  to  provide  further 
explanations  of  the  task. 

AlrPlan  Is  an  artificial  Intelligence  system  that  assists  In  launch 
and  recovery  of  aircraft.  AlrPlan’s  function  Is  to  notify  decision 
makers  when  current  options  change  (e.g.  proposed  landing  site  no  longer 
attainable  due  to  fuel  shortage).  ZOG  provides  input  and  output 
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interface  to  AirPlan;  allowing  users  to  update  scenarios  through  ZOG  and 
then  receive  information  back  in  ZOG  frames  (nodes)  (56:303-304). 

Hypertext  Medical  Handbook.  The  Washington  University  School  of 
Medicine  in  St  Louis,  Missouri,  is  working  on  an  application  that  will 
provide  a  hypertext  medical  handbook.  Two  areas  of  concern  are  being 
focused  on:  how  to  assist  the  authors  and  editors  of  the  handbook  and 
how  can  information  be  retrieved  from  an  online  manual. 

To  automate  the  paper  manual,  four  steps  were  required.  First,  the 
manual  was  partitioned  into  individual  nodes  based  upon  the  original 
hierarchical  structure  of  the  paper  manual.  Then  each  node  was  assigned 
a  title  based  upon  the  nodes  first  six  words  (this  was  later  used  to 
label  links).  Next  a  parser  was  used,  creating  automatic  links  between 
nodes  to  maintain  the  linear  relationships.  The  final  step  was  further 
indexing  and  retrieval. 

Several  methods  are  available  to  the  user  for  finding  information 
in  this  hypertext  medical  handbook:  pattern  matching  (i.e  key  word 
search),  simple  graphical  browsing,  and  heuristics  for  finding  optimal 
locations  to  start  graphical  browsing. 

The  developers  of  this  system  are  also  looking  at  further  enhance¬ 
ments  to  Increase  the  capability  of  the  system:  highlighting  for 
emphasis,  annotation,  page  turner  links,  permanent  path  marking, 
bookmarks,  clipboards,  and  agenda-keepers  (34:880-886). 

Other  medical  hypertext  projects  are  also  being  developed,  a  drug 
information  database  at  Johns  Hopkins  Hospital,  a  textbook  of  internal 
medicine  (InforMed  Project)  at  Columbia-Presbyterian  Hospital,  and  a 
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knowledge  management  system  for  diagnosis  and  pathophysiology  at  Harvard 
Medical  School  (74:24). 

Other  Reference  Books.  The  Oxford  English  Dictionary  (OED)  has 
been  keyed  In  to  the  computer  as  a  hypertext  system  and  Is  currently 
available  on  compact  disk,  read  only  memory  (CD-ROM)  (65:871-879, 
63:292).  Research  on  an  electronic  encyclopedia  is  being  conducted  by 
the  University  of  Maryland  and  the  University  of  Washington  (83:63-88; 
73:189-194). 

Educational  Applications.  Hypertext  and  hypermedia  are  being  used 
In  several  educational  applications.  Brown  University’s  Institute  for 
Research  in  Information  and  Scholarship  (IRIS)  is  completing  a  research 
project  (Educational  Software  Program  (ESP))  designed  to  explore  the 
possibilities  of  non-lineal  thinking  in  human  cognition.  Courses  in 
English  Literature  and  Plant  Cell  Biology  were  augmented  with  hypertext 
(76:35;  82:891;  84:12-25;  5:67-88)  to  supplement  information  provided  in 
regular  classroom  instruction.  The  literature  class  hypertext  includes 
biographical  sketches,  explanatory  essays,  portraits,  art  works,  and 
timelines  (84:18-20;  76:35).  The  biology  class  uses  linking  of  online 
lecture  notes  to  cell  models  and  experiment  diagrams  so  students  can 
"better  integrate  the  material”  (76:35). 

Several  departments  at  the  University  of  Southern  California  are 

working  on  a  joint  project  (Project  Jefferson)  to: 

provide  a  computerized  program  that  will  Integrate  the  assign¬ 
ments  of  the  Freshman  Writing  Program  classes,  the  pedagogical 
goals  of  the  Instructors,  the  teaching  of  library  and  research 
skills,  and  the  ability  to  access  online  information  with  a 
minimum  of  training.  (46:34) 
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Cornell  Medical  College  has  loaded  its  second-year  curriculum  into 
a  hypertext  system  which  also  allows  access  to  a  library  of  related 
graphics  and  pictures.  Their  final  goal  is  to  have  the  entire  cur¬ 
riculum  in  a  single  hypertext  system  with  access  to  textbooks  and 
reference  books  (69:171). 

Project  Perseus  at  Harvard  University  explores  how  hypertext  can 
improve  research  in  the  classics.  Instructors  and  students  are  working 
on  an  extensive  system  of  linked  classical  literature  to  encourage  and 
speed  the  research  process  (19:51-55;  46:34). 

Other  hypermedia  projects  In  education  and  business  are  discussed 
in  Interactive  Multimedia  by  Ambron  (3). 

Department  of  Oefense  Use  of  Hypertext 

Hypertext  use  and  research  within  the  Department  of  Defense  (DOD) 
appears  to  be  in  the  Initial  stages  yet.  The  literature  indicated  only 
three  specific  DOD  uses  of  hypertext. 

The  first,  and  earliest,  Indication  of  DOD  use  was  aboard  the 
U.S.S.  Carl  Vinson.  This  ten  year  project,  started  In  1980,  aboard  the 
USS  Carl  Vinson  provided  a  computer-assisted  management  system  (1;  2; 

56;  68).  It  Is  described  in  detail  earlier  in  this  chapter. 

The  second  use  of  hypertext  began  with  the  Hypermedia  Laboratory, 

In  1988,  under  the  Defense  Applied  Information  Technology  Center.  The 
overall  goal  of  the  laboratory  was  to  "create  artificial  intelligence 
and  hypermedia  based  programs  that  make  the  human-machine  interface  more 
human  in  the  machine’s  responses"  (48:1).  One  specific  project  of  the 
lab’s  was  to  develop  a  desktop  environment  with  artificial  intelligence 
and  hypertext  for  the  DOD  Gateway  Information  System  (DGIS)  (48;  50; 
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49).  DGIS,  as  the  core  computer  system  of  the  Defense  Applied  Informa¬ 
tion  Technology  Center  (DAITC) ,  serves  two  basic  purposes.  First,  it 
serves  the  DOD  community  by  aggregating  information  from  a  variety  of 
Information  systems  into  a  useful  product.  Second,  it  serves  as  a 
prototype  environment  for  enhancing  information  access  within  the  DOD 
community  (51:1).  Another  related  project,  on  a  super  mini-computer, 
allows  the  user  to  jump  around  in  a  database  using  hypertext  and  has  a 
goal  of  developing  a  hypertext  template  to  allow  non-programmers  to 
create  their  own  applications  (10).  The  Hypermedia  Laboratory  has  since 
been  deactivated  (9). 

The  third  use  was  a  two  year  project,  begun  in  1988,  designing  a 
system  to  provide  rapid  access  to  relevant  text,  forms,  and  graphics 
from  Army  regulations  and  training  literature.  The  application  uses 
table  of  contents,  Indexing,  browsing,  and  suggestions  for  further 
reading  to  aid  the  user  in  finding  the  needed  information  (79;  67).  The 
purpose  of  this  document  management  system  was  to  assist  Army  personnel 
in:  "learning  specific  concepts  and  their  interrelationships,  authoring 
a  document  of  their  own,  or  preparing  specific  forms"  (79:569-570). 

Other  than  the  three  examples  above,  the  only  indication  that  the 
DOD  is  using  hypertext  appears  In  acknowledgements  of  articles.  The 
Army,  Air  Force,  and  Navy  are  contracting  for  general  research  at 
private  Institutions  and  companies  (75;  36;  32;  20;  15;  27;  35;  30). 

Factors  Affecting  Hypertext  Usability 

The  literature  in  this  area  consistently  Identifies  one  fact:  more 
research  is  required;  few  empirical  studies  have  been  done;  and  "ex¬ 
tremely  few  studies  exist  of  the  real  world  Impact  of  using  hypertext 
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systems,  possibly  because  hypertext  has  not  been  used  all  that  much  yet 
for  real  world  tasks"  (58:245).  Because  of  the  limited  research  on 
hypertext  usability,  this  section  presents  several  articles  that,  while 
not  specifically  dealing  with  hypertext,  may  bear  on  its  use.  This 
review  is  not  intended  to  be  all  Inclusive,  rather  it  presents  a  brief 
commentary  in  each  area  of  concern.  The  developer/author  needs  to  be 
aware  of  these  areas  in  the  design  of  a  hypertext  system. 

When  considering  whether  to  use  an  automated  hypertext  system  for 
office  reference  or  learning,  one  of  the  first  things  that  must  be 
discussed  is  the  affect  of  presentation  method  on  user  reading,  com¬ 
prehension,  and  selection. 

Oborne  cites  studies  reviewing  the  difference  between  reading  from 
screen  versus  paper,  which  hypothesized  that  reading  from  a  computer 
screen  would  take  longer  than  paper  and  reader  comprehension  would  be 
lower.  Five  studies  supported  a  screen  disadvantage;  three  studies  did 
not  support  the  screen  disadvantage:  and,  one  study  indicated  a  screen 
advantage.  Among  the  reasons  postulated  for  the  screen  disadvantage 
were  unfamiliarity  with  reading  from  the  screen,  differing  page  layouts, 
and  contrast  differences  between  paper  and  screen  (62:2-3). 

Oborne’ s  own  study,  designed  to  control  the  above  factors,  showed 
no  difference  In  reading  speed  and  comprehension  between  screen  versus 
paper  display  and  negative  versus  positive  character  display.  Preferen¬ 
ces  cited  by  the  research  subjects,  however,  were  for  paper  presentation 
with  dark  characters  on  a  light  background,  indicating  that  it  was  "most 
pleasing”,  "easiest  to  read",  and  "preferred  more"  (62:5-6).  This 
agrees  with  other  studies  reviewed  by  Oborne  which  cited  faster  and  more 
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accurate  reading  with  reduced  contrast  ratios  between  characters  and 
their  backgrounds  or  with  dark  characters  on  a  light  background  (62:3). 

Another  experiment  compared  performance  based  upon  lines  of  text 
displayed  on  the  screen:  9,  18,  and  34.  Dense  single  spaced  text  of  34 
lines  per  screen  was  least  preferred  while  performance  times  for  the  9 
and  18  line  versions  were  similar  (73:192). 

Granda,  in  a  study  of  229  computer  users,  found  that  user  selected 
help  gave  better  performance  and  users  of  hard  copy  help  performed 
better  than  online  users  (37:37).  The  same  study  reviewed  the  use  and 
effectiveness  of  several  help  sources:  human,  paper,  and  various  types 
of  online  Information.  Each  source  had  differing  selection  rates;  human 
help  was  selected  by  54  to  63  percent  of  the  users,  printed  documents  by 
58  percent,  and  online  by  51  to  61  percent.  The  time  to  find  the 
required  information  varied  according  to  source;  human  assistance 
required  the  longest  time  (24  minutes),  followed  by  printed  (10  minutes) 
and  online  assistance  (9  minutes)  (37:39-40). 

The  research  then  looked  at  each  of  the  three  sources  and  charac¬ 
terized  them  according  to  availability,  depth  of  knowledge,  and  diagnos¬ 
tic  capabilities.  It  was  felt  that  these  factors  would  affect  when  each 
help  source  is  selected  and  the  amount  of  success  achieved.  Avail¬ 
ability  of  online  help  is  high  (provided  it  is  installed)  while  human 
and  printed  availability  Is  varied.  Depth  of  knowledge  for  printed  help 
Is  high  while  human  and  online  are  varied.  Diagnostic  capabilities  of 
humans  are  high  while  online  Is  low  to  medium  and  printed  Is  low. 
Overall,  human  assistance  was  rated  highest,  followed  by  printed 
documents,  and  lastly,  by  online  documents  (37:40-42). 
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Granda  concluded  that  four  areas  account  for  the  more  frequent  use 

and  higher  ratings  for  human  help  sources. 

1)  Humans  are  interactive.  .  .  .  [I]n  response  to  .  .  .  lin¬ 
guistic,  visual,  and  auditory  cues,  humans  can  quickly  change 
the  conversation  to  meet  immediate  requirements  .  .  .[;]  they 
can  tailor  statements  to  maximize  the  degree  of  Interaction.  . 


2)  Humans  are  selective.  A  human  consultant  can  provide  only 
the  Information  required;  other,  irrelevant  information  can  be 
excluded.  .  .  . 

3)  Humans  can  engage  in  query  at  multiple  levels  of  dialogue. 

The  user  can  ask  the  human  consultant  questions  to  define  terms 
and  clarify  ambiguities  at  many  levels. 

4)  Humans  can  make  assessments.  A  human  consultant  can  ask 
the  user  questions  to  ascertain  the  level  of  understanding  and 
diagnose  the  difficulties.  (37:42) 

Granda  further  states  that  online  information  could  be  Improved  if 
made  more  like  a  human  source,  with  Interaction,  selectivity,  query 
format,  and  assessment  capability  (37:43). 

The  next  step  in  assessment  of  a  hypertext  system  concerns  the 
structure  of  the  document  Itself.  Several  articles  present  information 
In  this  area.  Responses  from  attendees  at  the  32nd  International 
Technical  Communication  Conference  Indicated  that  format  and  the  ability 
to  move  through  an  online  Information  system  were  the  most  important 
characteristics  of  an  online  help  system  (38:26).  Information  with 
well-defined  structures  and  clear  signals  of  shifts  from  one  part  of  the 
structure  to  the  next  have  proven  to  increase  reader  understanding  and 
learning.  A  poor  presentation  order  can,  on  the  other  hand,  impair 
learning  (17:110).  This  might  cause  a  problem  in  hypertext  systems, 
where  users  are  given  more  control  over  the  structuring  of  material. 
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Based  upon  database  research,  Raymond  concludes  that  the  structure 
of  a  hypertext  document  can  be  made  more  effective  by  reducing  the 
number  of  steps  required  to  navigate  the  document.  He  suggests  this  be 
done  through  the  use  of  multi-menus  which  permit  a  broader  base  of 
comparison  up  front  and  give  the  user  multiple  paths  and  levels  that  can 
be  explored  (66:254).  Other  researchers  support  this  idea  of  breadth 
overview  and  further  add  that  menus  of  link  descriptions,  global  and 
local  maps,  Indexes,  and  table  of  contents  may  be  helpful  (52:335-336; 
57:300,  79:572-576). 

There  is  disagreement  in  the  literature  on  how  these  menus  should 
be  presented,  however.  Akscyn  recommends  the  use  of  breadth  first 
frames  (explicit  menus)  to  provide  a  tree-like  overview  of  all  descen¬ 
dant  frames,  saying  that  this  provides  for  strong  hierarchical  structure 
(2:118-119).  Koved,  rather  than  supporting  explicit  menus,  as  Akscyn 
recommends,  provides  empirical  evidence  for  the  use  of  implicit  embedded 
menus.  Implicit  embedded  menus  differ  from  explicit  menus  in  that  high¬ 
lighted  words  within  text  blocks  become  menu  items  (47:312). 

In  a  test  comparing  explicit  tree-like  menus  to  implicit  embedded 
menus,  embedded  menus  showed  more  questions  were  answered  correctly, 
fewer  screens  were  viewed,  and  subjects  preferred  embedded  menus.  A 
second  test  compared  the  use  of  embedded  menus  to  page-turning  commands 
(first,  next,  etc.).  The  subjects  again  preferred  embedded  menus  even 
though  more  screens  needed  to  be  viewed  than  with  the  page-turning 
method.  Another  experiment  combined  embedded  menus  with  a  p  ning 
technique  (to  trim  currently  Irrelevant  text).  With  this  "novel" 
technique,  fewer  pages  were  viewed,  less  time  was  spent  reviewing  each 
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page,  and  less  than  half  the  time  was  required  to  solve  problems 
(47:316-317). 

Koved  acknowledges  one  negative  aspect  of  embedded  menus,  however. 
With  embedded  menus,  a  frequent  user  of  the  hyperdocument  would  be 
required  to  traverse  familiar  paths  to  access  the  details  needed.  He 
recommends  shortcuts  or  command  language  as  a  way  to  bypass  unneeded 
menus  (47:316). 

IBM’s  study  by  Granda  also  considers  the  different  information 
needs  based  on  user  knowledge  level.  Granda  classifies  help  users  along 
a  continuum  by  their  cognitive  state,  learning,  solving,  or  refreshing. 
He  based  this  continuum  on  descriptive  user  responses  describing 
problems  encountered,  "I  was  learning  to  do  X  .  .  .  I  was  solving  the 
problem  of  making  Y  work  .  .  .  [and]  I  was  refreshing  my  memory  on  the  Z 
facility  .  .  .  [underlines  added]  (37:39). 

Study  results  showed  that  learners  were  less  focussed  in  their 
information  search  and  both  learners  and  solvers  required  more  time  to 
find  the  needed  information  (37:39-40).  This  was  supported  by  Gil foil, 
who  tracked  the  amount  and  type  of  help  that  was  used  while  learning  a 
computer  system.  He  found  that  users  seek  general  help  while  learning 
and  more  specific  help  as  knowledge  grows  (37:36).  8ased  on  these 
results,  Granda  concludes  that  learners  and  solvers  could  benefit  from 
greater  guidance  in  information  search.  For  online  Information  to  be 
effective,  he  says  It  "should  be  designed  to  account  for  the  different 
[cognitive]  characteristics"  of  learning,  solving,  and  refreshing 
(37:43). 
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A  final  consideration  in  the  provision  of  an  online  information 
reference  is,  "will  people  use  it?"  Grice  identifies  three  factors  that 
are  critical  if  online  Information  is  to  be  used. 

1.  Useful —  ...  It  must  support  their  work  and  be  the  type 
of  information  they  need  in  the  format  they  want  it. 

2.  Easy  to  use —  .  .  .  [ I ] t  must  be  developed  based  upon  what 
has  been  learned  from  analyzing  the  audience  for  the  informa¬ 
tion  and  the  tasks  that  they  will  perform.  Once  the  informa¬ 
tion  is  developed,  it  must  be  reviewed  and  tested,  revised 
based  upon  the  reviews  and  tests,  and  tested  again  to  ensure 
that  it  is  accurate  and  suitable. 

3.  Possibly  attractive  and  enjoyable— but  function  and  usabil¬ 
ity  must  not  be  sacrificed  for  the  sake  of  appearance  alone. 

Of  course,  online  information  can,  and  should,  be  designed  to 
be  attractive  as  well  as  useful.  (38:34) 

Grice  then  goes  on  to  discuss  designer  choices  that  will  affect  the 
above  factors  in  the  success  of  the  online  Information.  These  are: 
familiarity  of  subject,  support  of  tasks,  ease  of  learning,  navi¬ 
gability,  ease  of  modification,  and  appearance  (38:35). 

Familiarity  Is  related  to  the  users  comfort  with  computers.  For 
individuals  unfamiliar  with  computers,  an  online  presentation  with  the 
same  conventions  and  format  as  printed  paper  will  make  users  more  at 
ease.  Also,  conventions  that  are  similar  to  what  users  have  experienced 
in  the  past  may  make  the  new  system  easier  to  learn.  All  frames  should 
look  and  act  the  same  for  "achieving  consistency,  familiarity,  and  ease 
of  navigation"  (38:35-37). 

Support  of  users’  tasks  Is  the  key  ingredient  in  making  a  system 
useful.  Grice  states  that  the  tasks  described  should  match  those  the 
users  perform  in  the  order  they  perform  them.  Further,  the  online  help 
should  be  easy  to  get  to  and  get  out  of  (38:37-38). 
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Ease  of  learning  and  first  use  create  a  first  impression  on  the 
users  that  affects  whether  they  will  use  the  online  information  again. 

A  poorly  designed  information  product  could  "scare  people  away"  so  they 
may  not  use  it.  Factors  that  influence  the  ease  of  learning  are: 
information  match  with  users  expectations,  degree  of  user  guidance 
offered,  task  complexity,  and  familiar  and  consistent  conventions 
(38:38). 

Navigability,  as  previously  mentioned,  is  one  of  the  disadvantages 
of  using  a  hypertext  document.  Grice  describes  several  actions  that  the 
designer  can  take  to  make  the  document  more  navigable. 

-  Guldeposts,  such  as  “screen  5",  "screen  1  of  8,"  .  .  . 

-  Actions  that  can  be  taken  ("push  key  x  to  do  this"  .  .  .) 

-  Identification  of  keys  that  can  be  used  to  take  action,  such 
as  ESCAPE,  END,  QUIT,  RETURN,  or  HELP. 

-  Identification  of  the  overall  context  (such  as  a  structure 
diagram  or  stack  map). 

-  Consideration  of  most  appropriate  use  of  disruptive  versus 
nondisruptive  functions  (such  as  Help).  (38:39) 

Grice  states  that  ease  of  modification  tends  to  make  the  users  more 
involved  and  comfortable  with  the  use  of  online  Information.  Modifica¬ 
tion  to  color,  menus,  abbreviations,  commands,  and  message  text  can 
often  be  allowed  without  having  a  major  affect  on  the  online  information 
(38:39). 

Appearance  of  an  online  information  system  Incorporates  four 

* 

factors,  font,  density,  color,  and  special  effects.  Grice  cites  smaller 
type  font  and  mixed  case  as  the  preferences  In  online  documents.  Dense 
text  slows  reading  on  screen.  Users  like  "color  for  a  reason"  rather 
than  indiscriminate  use  of  color;  excess  use  of  color  can  be  a  distrac- 
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tion.  Special  effects  Include  sound,  animation,  blinking,  color 
changes,  and  text  buildup.  As  with  color,  overuse  of  these  techniques 
tend  to  be  a  distraction  (38:40-41). 

Although  each  of  the  above  studies  provides  information  individual¬ 
ly  that  is  important  in  the  design  and  use  of  a  hypertext  system,  one 
noteworthy  study  by  Nielsen  compiles  the  results  of  30  different  papers 
and  92  benchmark  measurements  affecting  the  usability  of  hypertext. 
Because  of  the  low  number  of  studies  on  any  given  aspect  of  usability, 
Nielsen  found  that  a  meta-analysis  comparing  the  results  of  studies 
addressing  the  same  issue  was  not  possible.  Rather,  his  research 
focused  on  reviewing  study  results  on  various  factors  effecting  usabil¬ 
ity  to  determine  the  most  important  issues  (58). 

Based  upon  analysis,  he  narrowed  the  98  factors  affecting  usability 
to  the  "matters  that  really  matter"--those  with  effects  greater  than  20 X 
between  the  two  conditions  studied.  The  results  of  his  research  are 
shown  in  Appendix  C  (58:240-245). 

Nielsen  found  the  factor  having  the  greatest  effect  was  based  on 
Individual  differences — age  of  the  user;  older  users  were  over  100 
percent  less  likely  to  use  a  hypertext  system  than  those  20  years  of  age 
or  less.  Items  rated  2,  3,  and  6  also  reflect  Individual  differences, 
leading  Nielsen  to  conclude  that  Individual  differences  have  the  most 
important  effect  on  hypertext  system  usability.  Of  the  top  ten  effects, 
two  (effects  8  and  10)  relate  to  differences  in  the  user’s  task,  leading 
Nielsen  to  conclude  that  the  user’s  task  is  second  In  effect  on  hyper¬ 
text  usability.  Finally,  five  effects  (effects  4,  9,  12,  13,  and  15) 
related  to  different  behavior  when  using  hypertext  compared  to  using 
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paper  or  another  computer  system.  Nielsen  concludes  from  this  that 


studies  covering  usability  aspects  of  other  medium  should  not  be  applied 
directly  to  hypertext  (58:243-245).  Based  upon  the  above  conclusions, 
Nielsen  makes  the  following  recommendations: 

-  Individual  differences  among  users[:]  .  .  .  make  sure  to  test 
with  subjects  who  are  representative  of  your  intended  users, 
since  different  people  will  perform  very  differently.  What  is 
best  for  one  group  of  users  may  not  be  best  for  another. 

-  The  effect  of  different  tasks:  People  having  different  tasks 
will  use  hypertext  systems  in  different  ways,  so  different 
hypertext  mechanism  are  needed  to  support  different  tasks.  .  . 

-  [0]ne  cannot  always  rely  on  having  the  results  of  usability 
studies  of  non-hypertext  computer  systems  transfer  to  apply 
also  to  the  usability  of  hypertext  systems,  so  you  are  advised 
to  exercise  caution  if  you  try  to  do  so.  (58:246) 


Legal  Implications 

Depending  upon  how  hypertext  technology  is  used,  it  may  cause 
difficulties  with  the  copyright  law.  Federal  copyright  law  provides 
five  distinct  rights,  "the  right  to  reproduce  a  work  (e.g.,  to  "copy")  . 
.  the  right  to  adapt  or  modify  a  work  (i.e.,  to  create  a  "derivative 
work"),  and  the  rights  to  publicly  distribute  copies  of  a  work,  to 
display  it  (e.g.,  on  a  computer  terminal),  or  to  perform  It"  (44:368). 

Copyright  law,  however,  does  provide  for  "fair  use". 

[T]he  fair  use  of  a  copyrighted  work,  .  .  .  for  purposes  such 
as  criticism,  comment,  news  reporting,  teaching  (Including 
multiple  copies  for  classroom  use),  scholarship,  or  research. 

Is  not  an  Infringement  of  copyright.  In  determining  whether 
the  use  made  of  a  work  In  any  particular  case  is  a  fair  use  the 
factors  to  be  considered  shall  Include: 

(1)  the  purpose  and  character  of  the  use,  including  whether 
such  use  is  of  a  commercial  nature  or  is  for  nonprofit  educa¬ 
tional  purposes; 

(2)  the  nature  of  the  copyrighted  work; 
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(3)  the  amount  and  substantiality  of  the  portion  used  in 
relation  to  the  copyrighted  work  as  a  whole;  and 

(4)  the  effect  of  the  use  upon  the  potential  market  for  or 
value  of  the  copyrighted  work.  (44:370) 

When  hypertext  involves  the  automation  of  already  existing  material 
the  copyright  law  must  be  considered. 

Future  of  Hypertext 

Hypertext  is  still  in  the  growing  stages;  much  has  been  written 
about  issues  that  must  be  considered  in  the  design  of  the  next  genera¬ 
tion  of  hypertext  systems  (18:60-63;  21:173,175;  39:841-851;  82:893- 
895;  83:65-66).  Some  Individuals  see  that  hypertext  will  incorporate 
techniques  from  simulation,  artificial  intelligence,  natural  language 
processing,  and  cognitive  science  (55:25;  83:65-66;  70).  Prior  research 
has  been  completed  at  AFIT  in  this  area  by  Florian  and  Liddle,  who  both 
developed  applications  combining  hypertext  with  artificial  Intelligence 
(33;  54). 

Summary 

This  chapter  presented  the  early  history  of  hypertext,  with  Its 
birth  in  1945  with  Vannevar  Bush,  who  foresaw  browsing  of  entire 
libraries  with  a  machine.  Further  work  was  delayed  for  twenty  years, 
however,  due  to  technology  limitations.  The  features  of  hypertext 
(links,  nodes,  and  browsing)  were  explained  and  examined  regarding  how 
they  differ  among  hypertext  systems.  Links  were  highlighted  as  the  key 
feature,  with  their  critical  capability  for  supporting  rapid  movement 
within  the  hyperdocument.  Orientation  tools  for  browsing  were  reviewed, 
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with  emphasis  on  graphical  browsers  as  the  most  common  method.  Features 
vary  depending  upon  the  intended  user,  scope,  and  application. 

There  is  no  standard  hypertext  system.  Features  vary  depending 
upon  the  intended  user,  scope  and  application.  Classifications  of 
hypertext  systems  are  also  not  standard  with  the  industry.  In  general, 
the  development  of  hypertext  has  followed  individual  paths  depending 
upon  the  needs  of  the  designer  and  user. 

Several  specific  applications  of  hypertext  were  discussed,  includ¬ 
ing:  aircraft  carrier  management  information  system,  medical  handbook, 
reference  books,  and  various  educational  applications.  Hypertext  is 
being  used  within  the  Department  of  Defense,  however,  there  is  no 
mechanism  to  keep  track  of  the  applications  or  findings. 

The  usability  of  hypertext  Is  effected  most  by  two  factors, 
individual  differences  among  hypertext  users  and  differences  in  tasks. 

Copyright  law  may  or  may  not  be  important  in  the  development  of  a 
computer  application.  A  hypertext  application  developer  needs  to  be 
aware  of  the  legal  Implications,  however,  so  they  can  be  considered 
upfront. 

The  future  of  hypertext  Is  seen  with  the  overlapping  of  several 
different  computer  technologies  to  provide  greater  versatility  and 
useabl 1 Ity. 
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III.  Methodology 

This  chapter  explains  the  methodology  used  to  answer  the  key 
research  question  areas  posed  In  Chapter  I,  Information  needed  for  the 
reference  system,  hypertext  system  development,  and  hypertext  applica¬ 
bility  for  use  with  an  office  reference  system.  In  addition,  it 
presents  a  review  of  the  literature  pertinent  to  the  development  of  the 
prototype.  Prototyping  is  examined  as  it  is  used  in  the  software 
development  life  cycle  and  justification  is  provided  for  its  use  in  this 
research.  The  remainder  of  the  chapter  follows  the  steps  in  proto¬ 
typing:  identify  basic  needs,  develop  working  model,  demo  in  context, 
implement  revisions,  and  prototype  done. 

Prototype  Development 

The  first  step  in  software  development  is  defining  the  product 
life-cycle  model  (29:37).  This  model  should  encompass  all  the  activi¬ 
ties  needed  to  define,  develop,  test,  deliver,  operate,  and  maintain  the 
final  software  product.  A  well  defined  life  cycle  model 

.  .  .  provides  a  basis  for  categorizing  and  controlling  the 
various  activities  required  to  develop  and  maintain  a  software 
product.  A  life-cycle  model  that  is  understood  and  accepted  by 
all  concerned  parties  improves  project  communication  and  enhan¬ 
ces  project  manageability,  resource  allocation,  cost  control, 
and  product  quality.  (29:37) 

For  this  thesis  the  standard  waterfall  life-cycle  model  is  modified 
to  include  prototyping.  The  waterfall  life-cycle  model  as  described  by 
Boehm  is  shown  in  Figure  3. 

Most  software  development  practices  specify  that  system  require¬ 
ments  be  totally  defined  prior  to  initial  system  design.  Prototyping, 
on  the  other  hand,  allows  the  definition  of  an  initial  set  of  needs, 
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followed  by  quick  implementation,  and  reiteration  of  the  design  as 
requirements  are  further  defined  (11:5).  An  effective  prototype  "must 
work,  realistically  approximate  the  actual  system’s  functionality,  be 
ergonomically  sound,  and  be  documented"  (11:58).  It  should  also  be 
large  enough  to  permit  both  general  and  lower  level  perspectives.  The 
final  prototype  should  define  requirements  adequately  for  both  the  user 
and  developer  (11:58-63). 


Revalidation 

Figure  3.  Waterfall  Model  of  Life  Cycle  (12:36) 


39 


Prototypes  are  considered  part  of  the  requirements  definition  stage 
of  the  life  cycle.  An  example  of  the  requirements  definition  using 
prototypes  Is  shown  In  Figure  4.  As  Figure  4  shows,  prototyping 
requirements  definition  fits  between  feasibility  and  product  design  of 
the  waterfall  model  in  Figure  3. 


Feasibility 


Yes 

-  Product 

Design 


Implement 

- 1 

Revisions/ 

Prototype 

Enhancements 

Done? 

Figure  4.  Requirements  Definition  by  Prototyping  (11:8,37) 


Bielawski  states  that  prototyping  is  important  for  large  knowledge 
base  problems  because  It  gives  four  advantages  over  development  of  an 
entire  system  first. 

1.  A  prototype  enables  the  developer  to  judge  whether  the 
system  is  feasible.  Being  unable  to  get  the  system  to  perform 
well  on  a  subset  of  the  intended  problem  suggests  that  the 
system  will  not  be  capable  of  handling  the  entire  problem.  .  . 
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2.  A  prototype  allows  the  developer  to  test  the  suitability  of 
the  development  tool  that  has  been  selected.  Testing  even  an 
incomplete  system  may  reveal  that  the  knowledge  representation 
scheme,  ...  or  its  user-interface  capabilities  may  be  inade¬ 
quate  for  the  problem  at  hand.  .  .  . 

3.  A  prototype  will  suggest  the  amount  of  time  required  to 
build  the  whole  system,  an  estimate  is  essential  for  determin¬ 
ing  cost/benefit  ratio.  As  a  result  of  the  prototyping  ex¬ 
perience,  developers  may  discover  that  their  initial  time 
estimate  was  either  too  optimistic  or  too  pessimistic. 

4.  If  developers  need  to  gain  support  of  a  supervisor  before 
building  an  expert  system  [or  hypertext  system],  one  means  of 
doing  so  is  to  present  the  supervisor  with  a  working  prototype 
of  the  system.  To  suggest  the  potential  the  potential  of  a 
fully  developed  system,  a  prototype  often  makes  a  more  convinc¬ 
ing  argument  than  even  a  cogent  and  well-prepared  verbal  or 
written  presentation  of  the  concept.  (8:161-162) 

Prototyping  is  used  for  this  thesis  because  of  the  following  benefits: 

-  Provides  a  vehicle  for  validating  requirements. 

-  Provides  a  facility  to  permit  assessment  of  the  impact  of  the 
system  on  the  whole  user  environment. 

-  Permits  early  life  cycle  testing  of  human/machine  interfaces. 

-  Alleviates  project  communication  problem.  (11:38-44) 

Prototypes  are  also  readily  modified  to  explore  different  behaviors  and 
can  grow  in  functionality  to  accommodate  new  demands  (53:32). 

Regardless  of  the  above  advantages,  however,  prototyping  is  only  a 
correct  strategy  if  the  following  conditions  exist: 

-  All  requirements  cannot  be  prespecified. 

-  Quick  build  tools  are  available. 

-  Inherent  communication  gap  between  project  participants 
exists. 

-  Active  system  model  is  required. 

-  Rigorous  approach  [prespecification]  is  correct  once  require¬ 
ments  are  known. 
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-  Extensive  iteration  is  necessary,  inevitable,  desirable,  and 
to  be  encouraged.  (11:28) 

Due  to  the  relative  newness  of  hypertext,  many  office  personnel  are 
not  familiar  with  its  capabilities.  A  working  model  is  essential  to 
help  define  hyperdocument  requirements  and  bridge  any  communication 
gaps.  By  selecting  a  system  that  does  not  require  programming  skills, 
iterative  models  can  be  quickly  modified  as  more  information  becomes 
known  about  the  requirements.  A  complete  review  of  user  requirements 
was  beyond  the  scope  of  this  research,  so  to  communicate  with  potential 
future  users  an  active  system  model  was  essential.  Once  an  office  is 
familiar  with  hypertext  capabilities,  prespecification  of  the  require¬ 
ments  would  be  appropriate,  with  product  development  following  the 
waterfall  1 ife-cycle  model . 

Identify  Basic  Needs 

The  first  step  in  a  hypertext  development  project  is  ascertaining 
that  the  planned  application  is  suitable  for  hypertext.  Three  at¬ 
tributes  should  be  satisfied,  "large  body  of  knowledge  separable  into 
smaller  components,  Interrelated  components,  and  user  needs  only  a  slice 
at  any  time"  (72:127).  These  attributes  were  satisfied  by  economic 
analysis,  so  identification  of  needs  progressed  to  the  next  steps. 

Further  identification  of  the  basic  needs  for  t.he  prototype 
development  consists  of  hypertext  software  selection  and  design  of  the 
knowledge  structure. 

Hypertext  Software  Selection.  The  hypertext  software  was  selected 
based  upon  several  criteria.  Some  of  the  many  features  that  should  be 
considered  in  system  selection  are: 
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-  management  of  nodes  ...  an  index  of  all  the  nodes/articles 
that  have  been  created,  .  .  .  will  be  of  great  benefit. 

-  indication  of  links  .  .  .should  be  simple  and  easy  to  manipu¬ 
late.  Marking  a  phrase  or  region  can  usually  be  accomplished 
easily,  but  then  It  should  also  be  easy  to  indicate  the  des¬ 
tination  of  the  link.  .  .  .  For  text  articles,  the  link  but¬ 
tons  should  move  with  the  words. 

-  the  range  of  editing  functions  available  ( i . e . ,  copying,  mov¬ 
ing,  insertion,  deletion,  global  change  within  an  article, 
etc. ) . 

-  the  availability  of  lists  of  link  names,  index  terms,  syno¬ 
nyms,  etc. 

-  the  range  of  display  formatting  commands  available. 

-  the  availability  of  search/ replace  functions  for  making 
global  changes  across  multiple  nodes. 

-  control  of  color  (text,  background):  color  can  make  the  text 
look  attractive,  but  it  can  also  be  distracting.  Since  users 
are  very  different  in  their  preferences  and  tasks,  it  should  be 
possible  for  users  to  reset  color  usage  parameters. 

-  the  capability  to  easily  switch  between  author  and  browser 
modes  to  test  ideas. 

-  accessing  CD-ROM,  videodisc,  or  other  devices:  new  devices 
are  emerging  regularly  with  remarkable  storage  capabilities. 

It  should  be  possible  to  access  information  on  a  variety  of 
devices. 

-  capability  to  export  files  to  other  systems. 

-  operability  on  a  local  area  network. 

-  multi-user,  network  &  distributed  databases. 

-  version  keeping  (can  old  versions  of  an  article  be  stored?). 

-  graphics  &  video  facilities:  are  there  embedded  graphics 
editors  and  mechanisms  for  exploring  the  videodisc. 

-  collaboration:  can  more  than  one  person  edit  the  database  at 
one  time?  Can  components  of  the  database  written  by  several 
people  be  merged  into  one  hypertext  database. 

-  data  compression:  compression  algorithms  can  reduce  the  size 
of  the  database  and  facilitate  distribution  of  disks  or  dis¬ 
semination  by  electronic  networks. 
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-  security  control:  is  there  password  control  for  the  database 
or  parts  of  it. 

-  encryption:  can  sensitive  nodes  by  encrypted? 

-  reliability:  does  the  software  perform  without  bugs,  and 
without  loosing  data. 

-  integration  with  other  software/hardware. 

-  browser  distribution:  does  every  user  of  the  hypertext  have 
to  acquire  a  copy  of  the  full  system  or  can  the  browsing  part 
be  included  with  the  database.  (72:121-124) 

In  the  final  selection  of  a  hypertext  system  for  use  in  an  office 
reference  capacity,  most  of  the  above  features  would  be  critical.  For 
the  prototype  development,  however,  not  all  features  were  considered 
essential.  For  the  prototype  the  following  were  considered  important: 
index  of  nodes,  easy  management  of  links,  wide  range  of  editing  func¬ 
tions,  capability  of  easy  switching  between  editor  and  browser,  version 
keeping,  data  compression,  reliability,  and  browser  distribution.  Also, 
several  additional  features  were  added  to  the  above  list  for  this 
prototype  development. 

Ease  of  development  was  considered  critical.  The  hypertext  system 
should  not  require  the  application  developer  to  possess  programming 
skills,  thereby  allowing  quicker  development  and  iteration.  Simple  non¬ 
programming  link  development  should  take  less  time  and  fewer  error 
corrections  than  programming  link  development.  This  might  also  be 
Important  for  selection  of  an  office  reference  system,  thereby  making 
the  software  more  usable  by  the  entire  office. 

Although  an  office  reference  system  may  be  more  appropriate  based 
on  another  computer,  to  aid  prototype  development  the  requirement  for  a 
microcomputer-based  hypertext  system  was  added.  The  appropriate 
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computer  level  (mainframe  access  through  DON,  minicomputer,  microcom¬ 
puter)  for  the  economic  analysis  reference  system  was  determined  during 
interviews  with  major  command  economic  analysis  experts  (Appendix  D).  A 
microcomputer  based  system  also  provided  better  capacity  to  test  the 
developed  reference  system.  The  microcomputer  system  allowed  test 
volunteers  to  review  the  prototype  on  their  own  computers. 

Many  commercial  companies  are  consolidating  hypertext  and  artifi¬ 
cial  intelligence  into  one  software  package.  Since  the  purpose  of  this 
thesis  was  to  test  hypertext  capabilities  only,  a  package  with  hypertext 
capability  only  was  desired.  For  a  review  of  the  capabilities  gained 
through  tleing  these  two  technologies  together,  however,  the  reader  is 
referred  to  the  two  AFIT  theses  mentioned  in  Chapter  II  (54;  33). 

The  literature  indicated  many  companies  provide  hypertext  software 
packages  (Appendix  E).  Unstructured  telephone  interviews  were  con¬ 
ducted  with  the  companies  and  demonstration  copies  of  disks  and  documen¬ 
tation  were  requested  so  the  systems  could  be  evaluated.  Also,  the  KMS 
hypertext  system  which  is  available  In  the  Air  Force  Institute  of 
Technology  Engineering  School  on  the  Sun  Workstation  was  considered. 

Knowledge  Structure  Design.  Design  of  the  knowledge  structure 
typically  consists  of  four  steps:  "specify  goals,  market  niche  & 
audience,  decide  on  scope  of  coverage,  Identify  list  of  topics  and 
components,  and  choose  traversal  structures"  (72:127-128). 

As  specified  in  Chapter  I,  a  complete  analysis  of  user  require¬ 
ments  (i.e.  goals,  audience)  was  beyond  the  scope  of  this  research.  The 
scope  of  the  prototype  included  a  adequate  number  of  reference  docu¬ 
ments  to  test  the  capability  of  hypertext  when  used  in  an  office 
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reference  system.  The  prototype  focused  on  adapting  the  selected 
reference  documents  to  hypertext  (i.e.,  breaking  into  nodes  and  link¬ 
ing). 

An  initial  list  of  topics  and  components  was  identified  through 
structured  telephone  interviews  with  economic  analysis  experts  from 
several  major  commands  and  schools:  Strategic  Air  Command,  Military 
Airlift  Command,  Tactical  Air  Command,  Air  Force  Cost  Center,  Sheppard 
AFB  Cost  Analysis  Technical  School,  and  Air  Force  Institute  of  Technol¬ 
ogy  Professional  Continuing  Education  (PCE).  The  interviews  determined 
what  reference  documents  are  used  to  prepare  economic  analyses,  the  most 
frequent  types  of  economic  analysis  performed,  and  the  knowledge  base  of 
the  preparer.  Other  questions  concentrated  on  the  most  common  problems 
in  economic  analysis  preparation,  with  the  prototype  then  concentrating 
on  better  methods  of  tying  together  documents  to  solve  the  problems. 

The  specific  questions  asked  are  shown  in  Appendix  D. 

To  test  the  concept  of  prototype  development,  an  economic  analysis 
instructor  from  the  Air  Force  Institute  of  Technology  functioned  as  the 
prototype  system  user.  Discussions  helped  determine  the  final  selection 
of  reference  documents  and  the  traversal  structure  for  the  hypertext 
system. 

Due  to  the  large  number  of  reference  documents  available  on 
economic  analysis,  selection  of  the  ones  to  include  In  the  office 
reference  system  required  some  thought. 

Selecting  documents  to  Incorporate  in  a  hypertext  document 
is  not  a  simple  problem.  The  goal  should  not  be  to  build  a 
hypertext  encyclopedia,  a  hypertext  reference  manual,  or  a 
hypertext  version  of  system  documentation.  Instead,  the  goal 
should  be  to  enhance  the  performance  or  enjoyment  of  people 
performing  their  jobs,  using  hypertext  when  it  is  appropriate 
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to  improve  the  access  to  and  the  usefulness  of  information. 

This  view  implies  that  the  choice  of  documents  to  include  in  a 
hypertext  should  be  dictated  by  a  user  and  task  analysis.  Only 
when  the  intended  users  must  combine  Information  from  more  than 
one  document  to  meet  the  information  needs  of  the  tasks  they 
carry  out  is  a  multi -document  hypertext  called  for.  .  .  . 

So  when  should  two  documents  be  integrated  in  a  multi¬ 
document  hypertext?  The  motivation  for  combining  more  than  one 
document  in  a  hypertext  is  the  conviction  that  each  document 
adds  value  to  the  others,  that  the  whole  is  greater  than  the 
sum  of  the  parts.  .  .  .  (36:51-52) 

Document  selection  was  not  a  great  problem  due  to  the  scope  of  this 
research  prototype.  In  a  full  reference  system  on  economic  analysis, 
however,  the  selection  of  documents  would  be  a  greater  concern. 


Develop  Working  Model 

Steps  in  Development.  Shneiderman  lists  several  steps  in  develop¬ 
ment  of  a  hypertext  document: 

-  Collect  or  create  material. 

-  Develop  a  style  sheet  for  writing  articles  and  creating 

links. 

-  Ensure  appropriate  cross  referencing  to  related  concepts. 

-  Arrange  for  editing  of  text  and  graphics. 

-  Secure  legal  permissions. 

-  Create  database  In  proper  formats  .  .  .  (72:128) 

The  analysis  In  this  stage  can  required  the  most  effort  of  proto¬ 
type  development,  as  was  the  case  with  the  Army  document  management 
system  discussed  In  Chapter  II.  The  document  management  prototype 
required  an  Initial  heavy  load  of  manhours  to  develop  an  understanding 
of  the  documents  and  the  selection  of  concepts  for  the  link  structure 
was  found  to  be  the  most  difficult  part  of  the  development.  The 
developers  of  the  Army  manual  project  found  the  most  time  consuming 
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effort,  however,  was  the  scanning,  proofreading,  and  correcting  of 
selected  information  (67:10). 

For  the  economic  analysis  reference  system  prototype  the  documents 
identified  in  knowledge  structure  design  were  collected  and  reviewed.  A 
flatbed  scanner  was  used  for  documents  not  available  in  computerized 
form.  The  scanner  transformed  printed  paper  copies  to  a  computerized 
file.  Since  existing  reference  documents  were  used,  a  style  sheet  was 
not  required.  Appropriate  cross  referencing  within  and  between  docu¬ 
ments  was  determined  after  establishing  the  basic  documents  in  the 
hypertext  system.  Cross  referencing  Is  explained  In  more  detail  later 
in  this  chapter.  Legal  permission  for  use  was  secured  where  necessary. 
In  creating  the  actual  hypertext  database,  the  following  information 
became  Important. 

Development  Considerations.  Creating  a  hypertext  document  in  the 
proper  format  require.?  additional  considerations  beyond  concerns  for 
good  writing.  The  following  list,  developed  by  Shneiderman,  is  based 
upon  years  of  experience  with  hypertext  document  development.  Each  of 
these  requirements  were  considered  In  the  development  of  the  prototype. 

1.  Know  the  users  and  their  tasks:  Users  are  a  vital  source 
of  Ideas  and  feedback;  use  them  throughout  the  development 
process  to  test  you  designs.  .  .  .  Study  the  target  population 
of  users  carefully  to  make  certain  you  know  how  the  system  will 
really  be  used.  Create  demonstrations  and  prototypes  early  in 
the  project;  don’t  wait  for  the  full  technology  to  be  avail¬ 
able. 

2.  Meaningful  structure  comes  first:  Build  the  project  around 
the  structuring  and  presentation  of  information,  not  around  the 
technology.  Develop  a  high  concept  for  the  body  of  information 
you  are  organizing.  Avoid  fuzzy  thinking  when  creating  the 
Information  structure. 

3.  Apply  diverse  skills:  Make  certain  that  the  project  team 
Includes  information  specialists  (trainers,  psychologists), 
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content  specialists  (users,  marketers),  and  technologists 
(systems  analysts,  programmers) ,  and  that  the  team  members  can 
communicate. 

4.  Respect  chunking:  The  information  to  be  presented  needs  to 
be  organized  into  small  "chunks"  that  deal  with  one  topic, 
theme,  or  idea.  Chunks  may  be  100  words  or  1000  words  but  when 
a  chunk  reaches  10,000  words  the  author  should  consider  re¬ 
structuring  Into  multiple  smaller  chunks.  .  .  . 

5.  Show  inter-relationships:  Each  document  should  contain 
links  to  other  documents.  The  more  links  contained  in  the 
documents,  the  richer  the  connectivity  of  the  hypertext.  Too 
few  links  means  that  the  medium  of  hypertext  may  be  inapprop¬ 
riate,  too  many  links  can  overwhelm  and  distract  the  reader.  . 


6.  Be  consistent  In  creating  document  names:  It  is  important 
to  keep  a  list  of  names  given  to  documents  as  they  are  created; 
otherwise,  it  becomes  difficult  to  identify  links  properly. 
Synonyms  can  be  used,  but  misleading  synonyms  can  be  confusing. 

7.  Work  from  a  master  reference  list:  Create  a  master  refer¬ 
ence  list  as  you  go  to  ensure  correct  citations  and  prevent 
redundant  or  missing  citations.  Some  hypertext  system  automat¬ 
ically  construct  this  list  for  you. 

8.  Ensure  simplicity  in  traversal:  Authors  should  design  the 
link  structure  so  that  navigation  is  simple,  intuitive,  and 
consistent  throughout  the  system.  Movement  through  the  system 
should  be  effortless  and  require  a  minimum  of  conscious  though- 
t.  Find  simple,  comprehensible,  and  global  structures  that  the 
readers  can  use  as  a  cognitive  map.  Be  sensitive  to  the  possi¬ 
bility  that  the  user  will  get  "lost  In  hyperspace"  and  develop 
the  system  so  recovery  is  simple. 

9.  Design  each  screen  carefully:  Screens  should  be  designed 
so  they  can  be  grasped  easily.  The  focus  of  attention  should 
be  clear,  headings  should  guide  the  reader,  links  should  be 
useful  guides  that  do  not  overwhelm  the  reader.  Visual  layout 
Is  very  Important  in  screen  design. 

10.  Require  low  cognitive  load:  Minimize  the  burden  on  the 
user’s  short-term  memory.  Do  not  require  the  user  to  remember 
things  from  one  screen  to  another.  The  goal  is  to  enable  users 
to  concentrate  on  their  tasks  and  the  contents  while  the  com¬ 
puter  vanishes. 

11.  Early  reviews:  Subject  the  database  to  technical,  legal, 
and  management  reviews  as  early  as  possible.  As  the  database 
becomes  larger,  changes  become  more  difficult  to  make. 
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12.  Maintain  multiple  perspectives:  When  authoring,  try  to 
balance  the  technical  requirements  of  the  system  with  the 
user’s  perspective  and  the  organizational  use  of  the  database. 
(72:125-126;  74:62-63) 

Know  the  Users.  The  current  manual  reference  system  is  used 
by  individuals  with  a  wide  range  of  knowledge  in  economic  analysis,  the 
same  would  be  true  of  any  automated  system  developed.  In  addition, 
users  of  an  automated  system  would  have  a  wide  range  of  knowledge  and 
experience  with  computer  operation.  The  range  of  knowledge  and  ex¬ 
perience  In  both  economic  analysis  and  computer  use  were  considered  in 
the  design  of  the  prototype.  Three  factors  were  important  in  this  area: 

.  .  .  Strive  for  consistency.  .  .  .  Consistent  sequences  of 
actions  should  be  required  in  similar  situations,  identical 
terminology  should  be  used  in  prompts,  menus,  and  help  screens, 
and  consistent  commands  should  be  employed  throughout.  .  .  . 

Enable  frequent  users  to  use  shortcuts.  As  the  frequency  of 
use  [and  knowledge  of  economic  analysis  and  computers]  in¬ 
creases,  so  does  the  desire  to  reduce  the  number  of  interac¬ 
tions  and  Increase  the  pace  of  interaction.  Abbreviations, 
special  keys,  hidden  commands,  and  macro  facilities  are  ap¬ 
preciated  by  frequent  knowledgeable  users.  .  .  . 

Reduce  short-term  memory  load.  The  limitation  of  human  Infor¬ 
mation  processing  in  short-term  memory  ("seven  plus  or  minus 
two  chunks")  requires  that  displays  be  kept  simple,  multiple 
page  displays  be  consolidated,  frequent  window  motion  be  re¬ 
duced,  and  sufficient  training  time  be  permitted  for  codes, 
mnemonics,  and  sequences  of  actions.  Where  appropriate,  online 
access  to  command  syntax  forms,  abbreviations,  codes,  and  other 
Information  should  be  provided.  (71:61-62) 

Structure  Comes  First.  According  to  literature,  the  introduc¬ 
tion  of  a  hypertext  document  needs  to  convey  the  subject  and  structure 
of  the  information  contained,  much  like  a  book's  table  of  contents. 

Three  strategies  are  possible: 

a.  Make  the  root  document  an  overview  that  contains  links  to 
all  major  concepts  in  the  database  [glossary  strategy]. 
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b.  Adopt  a  hierarchical  approach  in  which  the  links  in  the 
root  document  are  major  categories  [top-down  strategy]. 

c.  Organize  the  root  article  as  a  list  or  table  of  contents  of 
the  major  concepts  in  the  database  [menu  strategy].  (72:126) 

Inter-relationships  of  Documents.  Since  the  economic  analysis 
reference  system  contains  more  than  one  document,  the  amount  of  integra¬ 
tion  between  documents  must  be  considered.  As  discussed  in  Chapter  II, 
excess  linking  causes  problems  of  disorientation  and  cognitive  over¬ 
load.  In  an  early  hypertext  model,  linking  of  multiple  documents  was  so 
extensive  that  structures  of  the  individual  documents  disappeared 
(36:55).  If  regulations  are  to  be  incorporated  into  the  reference 
system,  however,  separate  structures  must  be  maintained.  Glushko 
presents  a  framework  for  linking  in  multi-document  hypertext  by  con¬ 
sidering  four  classes  of  links. 

Explicit  Intra-document  links  Links  of  this  class  explicitly 
connect  two  parts  of  the  same  document,  and  Include  footnotes, 

"See  also"  cross-references,  and  pointers  to  figures,  illustra¬ 
tions,  or  other  nontextual  components.  These  links  are  the 
easiest  to  Identify  when  converting  existing  texts  to  hypertext 
and  they  are  probably  the  most  usable  and  useful  as  well.  .  .  . 

As  a  result,  when  printed  documents  are  converted  to  elec¬ 
tronic  ones  It  Is  essential  to  exploit  this  sort  of  knowledge 
by  capturing  the  explicit  Intra-document  links  first. 

Implicit  Intra-document  links  These  links  are  those  that  are 
part  of  the  logical  structure  of  the  document  but  which  may  be 
impossible  to  make  explicit  In  the  printed  form  because  of 
limitations  In  the  medium,  the  nature  of  the  writing  and  pro¬ 
duction  process,  or  publishing  conventions.  For  example,  .  .  . 
the  first  appearance  of  a  Glossary  item  In  the  text  can  readily 
be  linked  to  its  definition  In  the  "back  of  the  book"  Glossary 
in  electronic  form.  We  think  that  links  of  this  type  pose 
little  risk  of  disorientation  or  cognitive  overload  because 
they  follow  naturally  from  the  printed  version  of  the  document, 
so  we  consider  them  nearly  as  important  as  the  explicit  intra¬ 
document  links. 

Explicit  Inter-document  links  Like  the  explicit  links  within  a 
document,  these  links  are  easy  to  Identify  because  they  follow 
presentation  conventions  in  the  printed  document  and  are  often 
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collected  in  the  reference  or  bibliography  sections.  Yet  we 
think  that  they  pose  more  challenges  for  the  hypertext  designed 
and  reader  than  intra-document  links,  because  It  Is  much  harder 
to  predict  the  extent  or  usefulness  of  the  Information  at  the 
end  of  the  link.  An  author  may  cite  another  document  for  many 
different  reasons  and  the  cited  documents  may  add  little  value. 
To  link  or  not  to  link  hinges  on  the  issue  of  complementarity  . 


Implicit  Inter-document  links  These  are  the  links  that  might 
be  closest  to  the  vision  of  hypertext,  namely  links  that  are 
not  explicit  between  related  documents  but  that  can  be  ex¬ 
tracted  by  careful  and  creative  analysis  of  the  two  texts  and 
the  relationship  between  them.  But,  .  .  .  there  is  no  consis¬ 
tent  "rhetoric  of  hypertext"  that  makes  it  easy  for  a  reader  to 
understand  what  such  links  mean  and  what  is  likely  to  appear  at 
the  link  destination.  .  .  .  (36:57-58) 

Glushko  emphasizes  that  the  intra-document  links  be  established 
before  attempting  to  use  inter-document  links  (36:58).  In  the  Army 
field  manual  project,  the  creation  of  a  linked  database  turned  out  to  be 
the  most  difficult  portion  of  the  entire  development  effort  (67:12). 


Demo  in  Context  (Test  and  Evaluation) 

Prototype  testing  and  evaluation  is  dependent  upon  how  many 
iterations  have  been  performed.  Testing  of  early  iterations  concen¬ 
trates  on: 

macro  acceptance  of  the  thrust  of  the  model  by  the  user.  Are 
we  in  the  ballpark?  .  .  .  [D]etect1on  of  gross  oversights.  Did 
we  miss  a  record  type?  [and]  user  familiarity  and  comfort  in 
operating  the  model.  (11:72) 

Testing  of  later  iterations  concentrates  on  "discovering  missing  or 
incorrect  function,  testing  ideas  and  suggestions,  [and]  improving  the 
user/system  interface”  (11:72).  Since  the  developed  prototype  was 
tested  only  once,  It  concentrated  on  the  level  of  macro  acceptance  by 
the  user. 
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The  design  of  a  hypertext  system  affects  the  useability  of  the 
reference  system.  The  author  (of  the  hyperdocument)  is  responsible  for 
providing  the  right  information  with  the  right  nodes  and  links.  The 
design  should  provide  two  characteristics  to  the  user,  accessibility  and 
relevance. 

Information  is  accessible  if  users  can  find  it  both  when  they 
know  what  they  are  looking  for  and  when  they  do  not.  Informa¬ 
tion  is  relevant  if  it  is  the  appropriate  type  and  size  of 
information  module,  both  comprehensible  and  useful.  The  key  to 
accessibility  and  relevance  for  specific  user  groups  is  a 
carefully  engineered  matrix  of  Information,  an  array  that 
enable  users  to  move  efficiently  on  clearly  mapped  paths 
through  nodes  of  Information  .  .  .  (41:47) 

In  testing  computer  systems  for  office  use,  three  measurable 

factors  are  considered  paramount,  ease  of  learning,  low  error  rates,  and 

subjective  satisfaction  (71:17).  Ease  of  learning  refers  to  the  time 

required  to  learn  the  commands  to  use  the  system;  error  rate  refers  to 

the  errors  made  in  carrying  out  a  specified  set  of  tasks;  and  subjective 

satisfaction  refers  to  how  much  users  liked  the  overall  aspects  of  the 

system  (71:14-15). 

Based  on  the  above  Information,  a  questionnaire  was  developed  for 
testing  the  prototype;  It  Is  shown  in  Appendix  F.  Volunteers  were 
solicited  from  the  Air  Force  Institute  of  Technology  community.  Student 
and  faculty  volunteers  were  asked  to  use  the  prototype  on  any  computer 
for  any  amount  of  time  and  then  answer  the  questionnaire.  AFIT  students 
from  the  both  the  1990  and  1991  classes  were  asked  to  participate  in  the 
test,  thereby  attempting  to  include  a  broader  spectrum  of  computer  know¬ 
ledge  in  the  test. 

Office  applicability  (update  capability  of  hypertext  to  accommodate 
regulation  changes)  was  also  partially  tested  during  system  development. 
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The  researcher  tested  this  capacity  by  adding,  deleting,  and  updating 
nodes  of  text  to  see  how  the  hypertext  network  reacted. 

Implement  Revisions 

Comments  from  the  first  demonstration  test  were  reviewed  and  used 
in  modification  of  the  structure  and  format  for  the  final  prototype. 
Modification  concentrated  on  improving  the  user  interface  and  general 
format  of  the  prototype. 

Summary 

Chapter  III  discussed  the  methodology  used  to  improve  the  economic 
analysis  reference  system  through  hypertext  automation.  The  use  of 
prototyping  was  explained  and  justified.  This  prototype  research 
Involved  a  four  step  process.  Identification  of  basic  needs  included 
the  hypertext  software  selection  and  design  of  the  knowledge  structure. 
Development  of  the  working  model  followed  specific  steps,  and  at  the 
same  time,  Incorporated  lessons  learned  over  years  of  prior  hypertext 
research.  Demonstrate  in  context  and  testing  was  done  through  a 
questionnaire  based  upon  those  factors  important  In  system  usability. 
Finally,  one  Iteration  in  prototype  development  was  made  based  upon 
comments  of  the  demo  in  context. 
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IV.  Results  and  Discussion 

This  chapter  describes  in  detail  how  the  methodology  of  the 
previous  chapter  was  followed.  It  is  separated  into  six  sections  that 
follow  the  prototyping  requirements  definition  as  shown  in  Figure  4  and 
explained  in  Chapter  III.  It  further  incorporates  and  answers  the 
research  questions  posed  in  Chapter  I. 

Hypertext  Software  Selection 

From  discussions  with  hypertext  software  companies  and  reviewing 
demonstration  packages  and  documentation  the  HyperWriter  hypertext 
software  was  selected  for  the  prototype  development.  Five  factors 
contributed  to  the  selection  of  HyperWriter: 

1.  No  programming  knowledge  was  required,  although  a  simple 
scripting  language  could  be  used  if  desired. 

2.  The  program  runs  on  an  IBM  compatible  microcomputer. 

3.  Single  use  system  (i.e.,  not  combined  with  artificial  intel¬ 
ligence). 

4.  Browser  distribution  is  unlimited. 

5.  Link  creation  is  very  easy. 

The  selection  of  HyperWriter  (TM)  for  this  research  does  not 
Indicate  or  imply  that  it  would  be  the  best  software  for  development  of 
a  total  economic  analysis  reference  system.  HyperWriter  was  selected 
because,  based  on  the  limited  number  of  software  packages  reviewed,  it 
appeared  to  best  fulfill  the  needed  criteria  to  demonstrate  the  concept. 
Appendix  G  provides  an  overview  of  HyperWriter’s  requirements  and 
capabilities. 


55 


A  microcomputer  hypertext-based  system  was  selected  for  the 
prototype  due  to  simplification  of  the  development  and  testing  effort. 
The  interviews  with  economic  analysis  experts  from  the  major  commands 
indicated  that  a  microcomputer-based  system  would  also  be  most  ap¬ 
propriate  for  use  throughout  the  Air  Force.  A  potential  problem  exists 
however,  due  to  the  varying  hardware  and  software  configurations  in  use 
in  the  target  offices  for  the  economic  analysis  reference  system  (13; 

78;  40;  77). 

Knowledge  Structure  Design 

Interviews  with  economic  analysis  experts  from  various  organiza¬ 
tions  revealed  varying  information  about  economic  analysis.  The  most 
frequently  identified  reference  sources  were  AFR  173-13,  U.S.  Air  Force 
Cost  and  Planning  Factors,  AFR  173-15,  Economic  Analysis  and  Program 
Evaluation  for  Resource  Management,  AFP  178-8,  Economic  Analysis  Proce¬ 
dures  Handbook,  The  Base  Level  Cost  Analysis  Handbook,  U.S.  Air  Force 
Military  Family  Housing  Economic  Analysis  Manual,  and  Military  Construc¬ 
tion  Program  Economic  Analysis  Manual.  Additional  locally  developed 
unique  information  was  also  used.  The  most  frequent  types  of  analyses 
performed  were  Military  Construction  Program  and  Military  Family  Housing 
Projects.  The  general  knowledge  level  of  individuals  preparing  analyses 
varied  from  untrained/uneducated  to  being  very  experienced  with  analyses 
techniques  and  processes.  There  appeared  to  be  no  consistent  problem 
area  with  analyses;  problems  cited  were  In  documentation,  misuse  of 
Indices  and  factors,  and  logic  (13;  78;  40;  77). 

Those  reference  documents  Indicated  by  the  Interviews  were  gathered 
and  used  as  the  basis  for  discussions  with  the  user.  The  user  suggested 
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the  course  text  for  QMT  345,  Economic  Analysis  for  Cost  &  Pricing  (64) 
as  another  source  of  information.  From  the  discussions,  it  was  decided 
to  center  the  prototype  on  information  from  The  Base  Level  Cost  Analysis 
Handbook  Chapter  11,  QMT  345  course  book,  and  regulations  (26;  64;  23). 
An  additional  document  used  in  the  prototype  was  an  economic  analysis 
checklist  developed  by  HQ  MAC  (28).  The  specific  thrust  of  the  proto¬ 
type  was  to  be  on  the  broad  concepts  of  economic  analysis  including 
terms,  definitions,  and  monetary  techniques  (45). 

Develop  Working  Model 

Documents  and  Structure.  The  documents  selected  for  the  prototype 
(23;  64;  26;  28)  were  gathered  and  prepared  for  use.  The  QMT  345  course 

book  was  already  available  in  computer  form  but  the  others  were  not.  A 
checklist  developed  by  HQ  MAC  scanned  with  minimal  errors.  Chapter  11 
of  the  handbook  was  scanned  in  with  some  success.  The  majority  of  the 
text  scanned  with  only  minor  errors  (10  to  15  per  page)  resulting  from 
slightly  illegible  print.  Pages  that  had  lines,  underlines,  smaller 
font,  nonstandard  symbols,  or  dense  text  resulted  in  many  more  errors 
per  page,  and  in  some  cases,  made  the  page  unscannable.  The  format  for 
AFR  173-15  (small  font,  two  columns,  condensed  print,  bold-face,  and 
lines)  made  it  virtually  unscannable.  Although  the  current  regulation 
was  not  available  in  computer  format,  a  draft  of  an  upcoming  revision  of 
AFR  173-15  was  available  on  the  computer.  Therefore  the  draft  regula¬ 
tion  was  used. 

While  the  scanning  of  good  quality  text  was  fast  and  required 
minimal  corrections,  poor  quality  text  resulted  in  the  need  for  many 
hours  of  correction.  Even  with  the  limited  number  of  references  used, 
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an  estimated  30  hours  were  spent  in  initial  corrections  and  formatting 

of  the  text.  The  above  problems  support  one  of  the  lessons  learned 

during  a  previous  hypertext  development  effort. 

If  you  are  going  to  rely  on  scanning  in  large  amounts  of  text, 
invest  in  the  best  quality  scanning  system  you  can  afford.  The 
one  we  selected  was  not  as  good  as  we  expected,  and  that  slowed 
us  down  considerably.  (67:14) 

All  references  selected  for  the  prototype  were  developed  by 
government  sources  except  one,  the  handbook.  Because  an  outside 
contractor  developed  this  for  the  Air  Force  the  copyright  laws  was  a 
concern.  Oiscussions  with  the  agency  who  the  handbook  was  developed 
for,  however,  revealed  that  the  handbook  could  be  reproduced  or  auto¬ 
mated  (16)  without  violation  of  copyright  law. 

The  development  considerations  discussed  in  Chapter  III  were 
important  in  the  next  step  of  creating  the  database  in  the  proper 
format.  This  document  and  link  structure  analysis  would  probably  have 
been  the  most  labor  intensive  part  of  the  development  effort  except  for 
software  problems  which  are  discussed  below.  An  estimated  30  hours  were 
initially  spent  on  document  analysis  prior  to  importing  any  information 
into  the  hypertext  system  and  another  20  were  required  once  the  docu¬ 
ments  were  imported.  More  time  spent  before  importing  the  text  could 
have  saved  time  later,  however,  as  the  researcher  found  herself  recon¬ 
sidering  and  changing  the  link  structure  while  developing  the  prototype. 
Peter  Beck  of  The  Analytic  Sciences  Corporation,  who  has  developed 
hypertext  applications  in  the  past,  also  found  this  to  be  one  of  the 
important  lessons  learned  when  starting  a  hypertext  project  (4). 

System  Development.  Because  >.e  wide  range  of  knowledge  of 
expected  users  made  consistency,  shortcuts  for  frequent  users,  and 
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reduced  memory  load  important,  certain  features  were  used  in  the 
prototype.  A  single  control  panel  was  used  to  provide  new  users  with  an 
interface  that  was  easy  to  learn  and  which  appeared  on  every  window  of 
the  reference  system.  The  features  in  the  control  panel  were  designed 
to  simplify  recovery  if  the  user  gets  lost.  The  top  of  Figure  5  shows 
the  control  panel  used  in  the  prototype.  Quicker  access  to  these  and 
additional  features  were  made  available  for  frequent  users  through  a 
pull-down  menu  system  and  function  keys.  Reduced  memory  was  facilitated 
in  three  ways,  through  HyperWriter’s  online  help  system,  a  help  system 
developed  as  part  of  the  prototype,  and  a  consistent  format  of  windows 
with  titles. 
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Ground  Buies  and.  Assumgt  Ions 
Alternatives 
(Costs* 

Benefits 
Comparison 
Ana  lysis 

3.  (Regulations* 

4.  (Def tnitlons* 


Figure  5.  Prototype’s  Table  of  Contents 


The  overall  structure  for  the  reference  system  was  based  on  the 
steps  in  economic  analysis  and  a  menu  strategy  with  table  of  contents  is 
the  starting  point  for  further  browsing.  The  main  portion  of  Figure  5 
shows  the  prototype’s  table  of  contents.  Further  structure  for  the 
reference  system  follows  a  card-based  design  which  limits  node  informa¬ 
tion  to  what  would  fit  within  each  screen. 

Once  the  selected  documents  were  Imported  into  the  hypertext  system 
and  linearly  linked  as  nodes  of  text,  additional  links  were  added  within 
and  between  documents  to  show  inter-relationships.  Explicit  and 
implicit  intra-document  links  were  used  freely  and  explicit  inter- 
document  links  were  used  where  specifically  indicated  by  wording  of  the 
text. 

The  first  iteration  of  the  prototype  file  was  88K  and  contained  160 
windows  with  250  links. 

Software  Problems.  As  mentioned  above,  some  software  problems  were 
encountered  in  the  development  effort.  Overall,  HyperWriter  was 
extremely  easy  to  learn  and  use;  the  researcher  learned  to  use  the 
system  in  one  weekend.  There  are  a  few  bugs  in  the  programming  that 
need  fixing,  but  nothing  that  prevents  adequate  use  of  all  the  intended 
functions.  The  problem  comes  In  the  error  checking  algorithms  of 
HyperWriter. 

One  action  that  may  cause  damaged  files  is  the  cutting,  copying,  or 
pasting  of  links  (61:94).  Ouring  restructuring  and  normal  edit  func¬ 
tions  on  the  imported  documents  cutting,  copying,  and  pasting  is  normal 
and  frequent.  The  first  step  In  any  of  these  operations  Is  marking  a 
block  of  text  for  action.  Being  human  means  that  eventually  a  link  will 
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accidently  be  marked  for  one  of  the  operations  causing  damaged  files. 

If  HyperWriter  then  queried  the  user  before  performing  the  damaging 
operation  no  inadvertent  file  damage  would  occur.  HyperWriter,  however, 
lets  the  user  blithely  corrupt  the  files,  which  occurred  several  times. 

A  second  undocumented  action  that  also  caused  erratic  results  and 
damaged  files  occurred  during  importing  of  text.  HyperWriter  requires 
ASCII  file  format  for  imported  text.  Again,  it  doesn’t  query  the  user 
if  the  file  format  is  incorrect.  Although  the  file  will  not  import 
correctly  some  unseen  characters  are  imported  into  that  HyperWriter 
window,  causing  later  problems  during  cutting,  copying,  and  pasting. 

Fixing  these  bugs  and  adding  error  query  algorithms,  the  Hyper¬ 
Writer  program  should  allow  very  quick  and  easy  development  of  an 
application.  NTERGAID  is  working  on  a  utility  that  will  allow  a 
developer  to  recover  from  corrupted  files.  At  the  current  time  the  only 
way  to  restore  a  corrupt  file  is  to  send  it  to  NTERGAID. 

Demo  in  Context 

One  Iteration  of  the  prototype  was  reviewed  and  tested.  In  the 
design  of  a  full  reference  system,  however,  early  and  frequent  reviews 
would  be  critical . 

Questionnaire  Results.  AFIT  student  volunteers  were  solicited  to 
test  the  prototype.  Of  the  60  students  who  volunteered  57  returned 
questionnaires,  for  a  95  percent  response  rate.  The  results  of  the 
questionnaire  are  shown  in  Appendix  H. 

Experienced  computer  users  were  the  predominant  respondents  in  the 
test  (88  percent).  This  Is  probably  not  representative  of  the  Air  Force 
community  who  would  be  using  the  reference  system.  The  volunteers 
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ranged  in  grade  from  0-2  to  0-4,  ranged  in  age  from  25  to  35,  and  all 
were  either  currently  working  on  a  masters  degree  or  had  recently 
completed  one.  A  complete  assessment  would  be  needed  to  determine  the 
individual  characteristics  of  the  end  users  of  an  economic  analysis 
reference  system,  but  undoubtedly  the  range  in  grade,  education,  and  age 
would  be  greater  than  those  testing  the  prototype. 

Few  volunteers  had  problems  installing  the  software  or  running  the 
prototype  with  the  simple  installation  instructions  (Appendix  I).  The 
majority  felt  that  the  opening  screen  was  sufficiently  explanatory  and 
adequate  to  allow  them  to  activate  links  to  the  online  help  system. 

The  researcher’s  Intention  in  designing  the  online  reference  system 
help  was  that  it  be  totally  self-sufficient  (i.e.,  no  documentation 
manual  required).  Based  on  the  responses  to  questions  about  the  online 
help,  only  34  percent  felt  that  a  users  manual  would  not  be  required. 

In  addition,  58  percent  Indicated  that  the  instructions  on  how  to  use 
the  system  needed  Improvement  and  29  percent  felt  that  the  online  help 
needed  Improving.  It  is  not  clear,  however,  whether  an  improvement  in 
the  online  Instructions  and  help  would  lead  more  Individuals  to  state 
that  a  users  manual  Isn’t  required.  Even  with  the  indications  that  more 
help  was  required,  67  percent  found  the  system  easy  to  learn  and  63 
percent  found  it  easy  to  use.  Only  23  and  16  percent  respectively  felt 
that  the  system  was  both  difficult  to  learn  and  use. 

The  control  panels  that  were  provided  to  assist  the  beginning  user 
received  mixed  reviews.  The  table  of  contents  function  was  the  most 
popular  control  Icon  (85  percent  found  it  useful)  and  the  least  useful 
was  the  past  history  function  (27  percent  found  it  useful).  The  other 
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control  icon  functions  in  order  of  usefulness  were  hypertext  help,  note, 
map,  tours,  and  index. 

The  testers  felt  that  a  hypertext  system  would  provide  a  useful 
office  reference  system  (79  percent).  In  that  capacity,  it  would  be 
most  useful  for  reviewing  familiar  material,  followed  in  order  by 
browsing  for  general  information,  first  time  learning  of  concepts, 
looking  up  an  answer  to  a  specific  question,  and  research  purposes. 

The  time  required  to  find  and  learn  information  on  a  hypertext 
system  compared  favorably  to  the  use  of  any  other  sources  of  informa¬ 
tion.  Users  stated  that  the  system  would  help  them  find  information 
more  easily  (83  percent),  would  take  them  less  time  (75  percent),  and 
they  would  learn  more  (69  percent).  If  they  had  access  to  a  hypertext 
reference  system,  44  percent  expected  to  use  it  at  least  once  or  twice  a 
day. 

The  features  most  liked  about  the  system  were  data  links  (70 
percent  liked),  functions  (53  percent)  and  speed  of  processing  (53 
percent).  In  contrast,  the  least  liked  features  were  instructions  on 
how  to  use  the  system  (58  percent  stated  improvement  was  needed),  depth 
and  breadth  of  data  (30  percent),  and  online  help  instructions  (28 
percent). 

Some  volunteers  who  tested  the  system  also  provided  comments  about 
the  prototype.  Their  comments  are  summarized  In  Appendix  J. 

Update  Capability.  The  software  selected  for  prototype  development 
allows  users  to  add  annotations  to  a  hypertext  document.  Because  of 
this  capability,  update  Is  simplified  somewhat.  As  changes  to  regula¬ 
tions  are  published,  indicating  the  change  is  as  simple  as  typing 


63 


information  in  a  window  called  from  the  control  panel.  Total  revisions 
to  regulations  are  not  as  simple.  A  complete  redevelopment  of  that 
document  and  existing  links  to  it  would  be  required.  Any  cutting  of 
currently  existing  links  could  cause  file  damage  as  discussed  above. 
Other  hypertext  system’s  capability  in  this  area  would  vary  however. 

Any  hypertext  system  would  have  to  be  reviewed  individually  to  determine 
its  support  for  updating. 

Implement  Revisions/Prototype  Done 

Comments  received  in  the  demonstration  and  test  were  incorporated 
into  the  prototype.  Specific  revisions  concentrated  on  supplementing 
and  improving  the  online  help  system.  The  final  prototype  developed  in 
this  research  effort  is  available  from  the  author. 

Summary 

Chapter  IV  presented  the  results  from  building  and  testing  the 
economic  analysis  office  reference  system.  The  HyperWriter  hypertext 
software  was  selected  because  of  its  ease  of  use,  microcomputer-base, 
and  unlimited  distribution  of  applications  with  the  runtime  browser. 

Four  documents  were  used  in  the  prototype  with  the  structure  and  links 
determined  by  the  researcher. 

The  demonstration  in  context  and  test  showed  the  prototype  was  easy 
to  use  and  learn  but  additional  work  was  required  In  either  supplemen¬ 
ting  the  online  help  or  developing  a  users  manual.  These  comments  were 
Implemented  and  the  final  prototype  is  available  through  the  author. 
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V.  Conclusions  and  Recommendations 

This  research  has  shown  that  hypertext  technology  can  be  used  to 
provide  a  very  practical  office  reference  system.  The  ease  of  both  use 
and  learning,  demonstrated  with  the  prototype,  shows  that  a  hypertext 
reference  system  can  be  effectively  used  in  an  office  environment; 
finding  information  would  be  quicker  and  users  would  learn  more.  In 
addition,  this  research  demonstrates  that  a  hypertext  reference  system 
can  be  used  by  individuals  with  a  wide  range  of  experience  and  reference 
requirements,  from  Initial  learning  to  reviewing  of  material.  The 
remainder  of  this  chapter  draws  conclusions  about  the  research  and  makes 
recommendations  for  further  research. 

Conclusions 

Three  general  areas  of  questions  were  answered  through  this 
research,  reference  documents  appropriate  for  the  prototype,  hypertext 
system  development,  and  office  environment  compatibility. 

Reference  Documents  Needed.  The  first  concern  was  the  determina¬ 
tion  of  appropriate  economic  analysis  documents  to  give  a  good  test  of 
the  hypertext  prototype  system.  Four  documents  were  selected  for  the 
prototype  development,  a  regulation,  a  handbook,  a  course  textbook,  and 
a  checklist.  Each  provided  a  different  unique  structure  and  covered 
varying  detailed  information  about  economic  analyses.  Some  inter¬ 
relationships  existed  between  the  documents  but  each  also  serves  a 
distinctive  purpose. 

The  second  challenge  was  getting  the  selected  documents  in  com¬ 
puterized  form.  One  document  was  available  in  computer  form,  scanning 
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was  attempted  on  the  other  three  to  simplify  and  speed  this  step.  While 
one  document  scanned  near  perfectly,  the  others  achieved  varied  success. 
Scanning  appears  to  be  an  option  only  with  "clean"  copy,  meaning  no 
underlines,  lines,  condensed  text,  font  differences,  nonstandard 
characters,  columns,  or  graphics.  If  any  of  the  above  conditions  exist 
in  quantity,  It  will  probably  be  quicker  to  reenter  the  information 
rather  than  correcting  nearly  illegible  scanned  text. 

Hypertext  System  Development.  Many  commercial  hypertext  software 
systems  exist  at  varying  prices.  Although  a  system  was  available  on  the 
SUN  workstation,  it  was  ruled  out  due  to  the  difficulties  in  development 
and  testing.  The  system  selection  was  based  not  on  cost  but  on  system 
capability.  Educational  pricing  is  available  from  many  software 
companies,  however. 

Based  on  interviews  with  several  major  commands,  the  most  approp¬ 
riate  system  base  is  a  microcomputer.  Even  this  could  cause  problems 
due  to  varying  hardware/software  configurations  at  different  bases. 
Before  development  of  a  full  reference  system,  a  more  complete  analysis 
would  be  required  to  determine  the  full  range  of  current  hardware/soft¬ 
ware  configurations  and  varying  hypertext  system  compatibility  with  the 
configurations. 

The  methodology  used  to  break  documents  into  text  blocks  (nodes) 
must  start  before  any  system  development.  Three  structures  are  recom¬ 
mended  to  simplify  the  Interface  and  access,  glossary  strategy,  top- 
down  strategy,  and  menu  strategy.  Based  on  the  structure  of  the 
selected  documents,  and  economic  analysis  in  general,  a  menu  strategy 
with  table  of  contents  was  the  most  appropriate.  Nonlinear  links  need 


66 


to  be  established  to  indicate  intra-document  relationships  first.  The 
next  step  is  establishing  of  explicit  inter-document  links  where 
relationships  clearly  exist  and  the  existence  of  the  link  provides 
useful  information. 

Differences  between  individual  users  and  tasks  should  be  a  primary 
consideration  in  development  of  the  user  Interface.  While  much  research 
has  been  done  on  improving  this  interface,  caution  must  be  used  In 
applying  the  results  of  studies  on  other  computer  mediums  directly  to 
hypertext.  More  research  In  real  world  applications  is  needed  before 
the  total  usability  of  hypertext  can  be  known. 

Office  Environment  Compatibility.  Based  upon  the  prototype  test, 
hypertext  use  is  compatible  with  the  office  reference  environment.  The 
reference  prototype  system  was  found  to  be  easy  to  use  and  learn  and 
capable  of  providing  quick  access  and  learning  of  Information. 

Update  capabilities  are  available  within  the  hypertext  software 
selected  for  the  prototype.  Annotation  nodes  allow  the  user  to  indicate 
office  unique  requirements  or  regulation  changes.  Complete  revisions  to 
regulations  will  require  some  redevelopment,  with  the  effort  required 
depending  on  the  hypertext  system  base  used. 

Recommendations  for  Future  Research 

Four  general  areas  exist  for  further  research.  The  first  deals 
with  government  use  of  hypertext  capabilities.  Research  on  hypertext  is 
being  accomplished  In  pockets  of  organizations  throughout  the  govern¬ 
ment,  each  working  In  a  vacuum.  An  indepth  review  of  organizations 
involved,  applications  tested,  real-life  systems,  and  research  findings 
could  be  a  starting  point  for  greater  use  of  hypertext  capabilities. 
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The  second  recommendation  deals  with  hypertext  software.  One 
system  was  used  in  this  prototype,  but  many  others  exist  that  may  have 
been  more  appropriate  for  use.  Further  research  should  be  conducted 
Into  what  software  systems  are  available,  what  individual  software 
requirements  and  abilities  are,  and  how  each  software  system  might  fit 
Into  the  needs  of  the  government.  The  determination  of  an  Air  Force 
supported  hypertext  system  could  save  money  and  aid  many  offices  In 
making  use  of  hypertext  capabilities  where  appropriate. 

The  third  and  fourth  recommendations  are  further  developments  on 
the  prototype  of  this  research.  The  third  recommendation  Is  for  a 
complete  user  needs  assessment  regarding  an  economic  analysis  reference 
system.  It  should  Identify  the  range  of  Individual  capabilities, 
specific  economic  analysis  reference  documents  required,  and  existing 
hardware/software  configurations.  This  needs  to  be  accomplished  before 
any  further  development  of  an  office  reference  system  for  economic 
analysis. 

The  fourth  recommendation  Is  to  continue  the  development  and 
testing  of  this  prototype.  Specifically,  further  research  needs  to  be 
done  on  how  to  Improve  the  user  Interface  for  an  office  reference 
system.  What  types  of  capabilities  need  to  be  added  to  make  an  office 
reference  system  that  can  be  used  by  Individuals  with  a  broad  range  of 
both  computer  and  knowledge  base  training  and  experience. 

Summary 

Chapter  I  described  the  current  problem  with  the  manual  economic 
analysis  reference  system,  Indicating  that  improvement  might  be  possible 
through  the  use  of  hypertext.  Chapter  II  provided  an  overview  of  what 
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hypertext  is,  how  it  is  being  used,  and  factors  affecting  usability. 
Chapter  III  defined  the  methodology  used  to  develop  and  test  the  proto¬ 
type  reference  system.  Chapter  IV  provided  comments  and  findings  from 
the  development  process  and  this  chapter  explains  how  the  research 
questions  were  answered  through  each  step  of  prototype  development. 

Four  areas  for  further  research  were  also  presented. 

In  addition  to  the  prototype  development  and  testing,  this  research 
was  designed  to  provide  a  single  first  reference  on  the  capabilities  and 
concerns  relating  to  hypertext. 
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Appendix  A:  CBT  Modules  on  Economic  Analysis 


1.  Title:  CBT  -  How  to  Document  an  Economic  Analysis 

a.  Version:  1.0 

b.  Description:  The  purpose  of  this  CBT  is  to  acquaint  the 
student  with  the  need  for  preparing  a  final  document  which  pulls 
together  all  of  the  work  done  in  an  economic  analysis  for  a  team  that 
will  review  and  make  final  decisions  on  problems  concerning  allocation 
of  scarce  resources.  By  the  end  of  the  lesson,  the  student  should  be 
able  to  correctly  place  all  of  the  elements  of  an  Economic  Analysis  in 
their  proper  order. 

c.  How  to  obtain:  Download  from  AFCSTC  Bulletin  Board  or  via  DON 
[Filename:  EADOC. ARC]  or  call  OPR  for  copy. 

d.  OPR:  Paula  Spinner,  SAF/FMCE,  AV  227-1152,  (202)  697-1152 

2.  Title:  CBT  -  Time  Value  of  Money. 

a.  Version:  1.0 

b.  Description:  This  a  basic  level,  mini-lesson  whose  purpose  is 
to  familiarize  the  student  with  terms  and  techniques  used  in  financial 
calculations.  By  the  end  of  the  lesson,  the  student  will  be  able  to 
calculate  present  and  future  values.  Ultimately,  this  mini-lesson  will 
be  incorporated  into  the  Economic  Analysis  module. 

c.  How  to  obtain:  Download  from  the  AFCSTC  Bulletin  Board  or  via 
DON  [Filename:  TVM.ARC]  or  call  OPR  for  copy. 

d.  OPR:  Paula  Spinner,  SAF/FMCE,  AV  227-1152,  (202)  697-1152 

3.  Title:  CBT  -  On  Economic  Analysis  (EA) 

a.  Version: 

b.  Description:  This  CBT  is  an  integration  of  a  CBT  lesson  on  an 
"Overview  of  the  EA  Process"  with  the  already  existing  "How  to  Document 
an  EA"  CBT  lesson.  The  purpose  of  this  module  is  to  familiarize  the 
student  with  the  step-wise  process  involved  in  developing  an  Economic 
Analysis.  The  lessons  to  be  Included  within  this  module  are: 

1)  Overview  of  an  EA 

2)  How  to  Document  an  EA 

By  the  end  of  the  lesson,  the  student  will  be  able  to  prepare  an 
economic  analysis. 
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c.  Schedule:  June  1990 

d.  OPR:  Paula  Spinner,  SAF/FMCE,  AV  227-1152,  (202)  697-1152  (2 
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Appendix  B:  Hypertext  Applications 


Note:  This  appendix  is  an  excerpt  from  the  documentation  for  Hyper- 
Writer  (61:177-194).  It  is  reprinted  here  with  permission  of  the 
authors.  Although  the  applications,  pros,  and  cons  listed  here  are 
specific  for  the  HyperWriter  software,  many  of  the  same  applications 
could  be  created  on  any  hypertext  system.  The  specific  applications 
outlined  here  can  be  downloaded  from  the  NTERGAID  Bulletin  Board  at  203- 
366-5698. 


Chapter  16:  Application  Building  in  HyperWriter 

Hypertext  is  based  on  an  amazingly  simple  idea  —  linking  disparate 
information  together  by  association  as  opposed  to  a  rigid  field/file 
organization.  This  idea  can  be  extrapolated  into  a  number  of  different 
applications  including  presentations,  personal  information  managers,  and 
much  more.  In  total,  nineteen  different  applications  are  detailed  here. 

Each  application  described  in  this  chapter  has  only  one  or  two  pages  to 
describe  it.  To  really  understand  this  chapter,  it  is  necessary  to  load 
the  HyperWriter  application  files  that  accompany  it  and  read  them 
concurrently  with  the  chapter.  All  the  applications  described  can  be 
accessed  from  the  document  APPLGUID.HW  —  an  index  to  these  applica¬ 
tions. 

An  overwhelming  advantage  to  each  of  these  applications  is  simply 
economy.  By  stretching  HyperWriter’s  functionality,  many  different 
applications  can  be  constructed  with  a  single  software  package.  This 
avoids  having  to  purchase  different  software  packages  that  might  go 
unused.  A  second  advantage  is  that  with  this  method,  you  only  need  to 
learn  a  single  software  package  as  opposed  to  several  packages. 

A  useful  approach  to  working  with  these  files,  should  you  choose  to  use 
them  for  your  own  purposes,  is  to  treat  each  file  as  a  'kernel’  docu¬ 
ment.  That  is,  remove  the  sample  data  provided  from  the  file  and  then 
use  that  file  without  data  as  a  basis  for  future  use. 

16.1  Application  #1:  Expert  System 

An  expert  system  is  a  type  of  computer  program  that  guides  a  user 
through  a  decision  tree  and  gives  him  ’expert’  advice  based  on  a 
predefined  knowledge  base.  The  basic  action  in  an  expert  system  is  that 
of  prompting  the  user  for  input  and  then  br  nching  to  the  next  question 
in  the  knowledge  base.  This  corresponds  to  the  action  of  selecting  a 
link  and  then  following  it  to  its  destination.  In  fact,  hypertext  can 
be  used  to  construct  nimple-to-moderate  expert  systems  that  guide  the 
user  to  an  answer  and  then  generate  a  report  of  the  result. 

The  demonstration  file  for  this  application  is  called  APPLY. HW.  Unlike 
many  demonstration  files,  APPLY. HW  is  part  of  a  commercially  available 
hypertext  application,  the  Reg-In-A-Box  oroject.  Reg-In-A-Box  is  a 
hypertext  document  written  by  the  EPA  to  provide  regulatory  information 
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in  a  hypertext  environment.  Reg-In-A-Box  first  became  available  in  the 
Fall  of  1989.  More  information  on  the  Reg-In-A-Box  can  be  found  by 
clicking  the  ‘About  Reg-In-A-Box ’  button  in  the  REGINBOX.HW  file. 

For  more  information  on  the  Reg-In-A-Box  project,  contact: 

United  States  Environment  Protection  Agency 

Bill  Foskett 

644  G.  Street  N.E. 

Washington,  DC  20002 

Generally,  expert  systems  constructed  within  HyperWriter  tend  to  be  on 
the  small  side,  with  between  100  to  200  rules  or  different  decision 
points.  This  reflects  the  very  highly  focused  nature  of  a  hypertext 
expert  system.  One  of  the  best  applications  for  a  hypertext  expert 
system  is  to  help  a  reader  find  information  inside  a  document.  In  any 
medium- to- large  size  document,  an  expert  system  can  be  created  that 
queries  the  reader  and  then  guides  him  or  her  to  the  correct  informa¬ 
tion. 


16.1.1  Pros 

The  overwhelming  advantage  of  this  approach  to  expert  systems  is  the 
ease  of  construction.  Traditionally,  constructing  an  expert  system  had 
been  a  complicated  task.  In  some  cases,  a  special  software  expert 
called  a  Knowledge  Engineer  was  needed.  Expert  systems  constructed  with 
HyperWriter  can  generally  be  created  by  the  author  of  the  document.  A 
second  advantage  is  that  special,  usually  expensive,  expert  system 
software  does  not  need  to  be  purchased.  In  addition,  HyperWriter’s 
runtime  can  be  used  to  distribute  expert  systems  for  free.  This  is  an 
option  that  many  expert  systems  do  not  come  with.  Finally,  Hyper- 
Writer’s  multiple  navigational  tools  can  often  be  used  to  gain  a  better 
understanding  of  the  knowledge  base  than  the  tools  that  accompany  a 
traditional  expert  system. 

16.1.2  Cons 

Despite  the  above  advantages  to  a  hypertext  expert  system,  there  are  a 
number  of  disadvantages.  To  start,  true  expert  system  programs  are  much 
more  flexible  for  an  expert  system  than  Is  HyperWriter.  A  true  expert 
system  can  not  only  accept  user  Input  but  can  also  do  calculations  with 
a  branching  based  on  this  input.  Second,  an  expert  system  provides 
extensive  facilities  for  ‘chaining’  or  reasoning  both  backwards  and 
forwards. 

16.2  Application  42:  DOS  Shell 

A  DOS  Shell  Is  a  program  that  provides  DOS  with  an  easier-to-use 
interface  than  DOS’s  traditional  command  line.  Often  a  DOS  Shell  is 
pictorial.  In  nature  replacing  commands  with  icons.  This  approach  is 
taken  here.  The  demonstration  file  for  this  application  is  DOSSHELL.HW. 
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16.2.1  Pros 


The  advantages  to  this  type  of  DOS  shell  are  simply  its  ease  of  con¬ 
struction  and  its  flexibility. 

16.2.2  Cons 

Some  of  the  disadvantages  with  this  DOS  Shell  are  the  disadvantages  with 
any  DOS  Shell  —  they  isolate  you  from  DOS.  Although  this  is  part  of 
their  goal,  usually  DOS  Shells  need  to  be  exited  at  one  time  or  another. 
And,  if  you  need  to  exit  a  DOS  Shell,  then,  really,  what  is  its  purpose? 
Our  DOS  Shell  application  relies  on  utility  programs  that  ship  with  the 
Norton  Utilities  (TM)  software  package  for  part  of  its  functionality. 
Finally,  this  DOS  Shell  does  not  have  the  sheer  functionality  that  a 
program  such  as  the  Norton  Commander  (TM)  has. 

16.3  Application  #3:  Office  Information  System 

One  of  the  very  first  major  hypertext  applications  created  for  Internal 
use  at  NTERGAID  is  what  we  call  MEMO  -  A  hypertext  memo  system  that 
manages  our  internal  communications.  The  Memo  system  is  chiefly 
composed  of  a  series  of  hypertext  files.  The  files  used  in  this 
application  are: 

File  Name 

MEMO. HW 
MEMO_BRI.HW 
MEMO_SCT . HW 
ARTICLE.TXT 
ARTICLE. HW 
DATES. HW 
AMOUNTS. HW 


Use 

Front  end  hypertext  document  to  all  files. 

Memos  from  Scott  to  Brian. 

Memos  from  Brian  to  Scott. 

Articles  from  magazines  and  networks. 

Titles  of  articles  and  commentary  on  them. 

Upcoming  dates  and  events.  NTERGAID. 

Upcoming  large  cash  expenditures  that  concern  NTER¬ 
GAID. 


This  collection  of  files  and  the  cross  links  between  them  manage  all  of 
NTERGAID’s  internal  communications.  This  is  a  fairly  complex  applica¬ 
tion;  the  best  way  to  understand  it  is  to  load  it  and  try  viewing  the 
different  files. 


As  a  backup  strategy  for  this  application,  all  files  are  simply  copied 
to  new  file  names  and  then  a  series  of  kernel  documents  are  used  to 
create  new  files. 


16.3.1  Pros 

The  overwhelming  advantage  to  this  application  is  simply  that  it  lets  us 
run  NTERGAID  much  more  efficiently.  By  formalizing  our  internal 
communications,  the  MEMO  application  has  reduced  the  human  factor  of 
memory. 
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One  disadvantage  to  this  application  is  simply  that  it  requires  human 
management  of  the  individual  files.  Some  degree  of  care  must  be  taken 
that  you  are  not  working  on  an  old  file  when  the  memo  file  is  updated. 

A  second  disadvantage  with  this  application  is  that  HyperWriter  isn’t  a 
multi-user  system.  However,  in  practice  this  is  not  really  a  problem 
for  us  because  of  our  working  habits.  The  people  thac  add  to  and  update 
this  application  typically  work  on  laptop  computers  in  isolation  from 
any  type  of  network.  By  designing  this  application  to  use  individual 
files  as  opposed  to  a  network,  this  most  closely  mirrors  our  working 
habits. 

16.4  Application  #4:  Educational  Courseware 

Educational  courseware  is  the  application  of  computer  software  to 
specific  courses.  This  has  resulted  in  the  term  courseware.  Courseware 
generally  tries  to  convey  large  quantities  of  course-specific  informa¬ 
tion  using  techniques  such  as  hypertext. 

The  demonstration  file  for  this  application  is  called  DEMO.HW.  This 
demonstration  file  Is  the  demo  disk  for  the  HyperWriter  application 
Culture  1.0  (TH).  Culture  is  a  four  megabyte  piece  of  educational 
courseware  that  covers  Western  culture.  This  demonstration  disk  gives  a 
good  flavor  of  the  facilities  that  a  well-designed  piece  of  courseware 
might  provide.  These  Include  both  text  and  graphics,  multiple  naviga¬ 
tional  tools  such  as  tours,  and  a  high  degree  of  user-interaction  via 
Hyperwriter’s  Readers  Notes  feature. 

A  second  courseware  demonstration  file  that  shows  how  to  use  HyperWriter 
for  multiple  choice  tests  is  called  HTTEST.HW.  This  file  constructs  a 
hypertext  multiple  choice  test  that  records  the  student’s  progress  to  an 
ASCII  file  called  GRADE. TST. 

A  different  approach  to  courseware,  not  illustrated  here,  is  that  of 
providing  students  with  raw  material  in  the  form  of  information  and  then 
allowing  them  to  link  it  together.  This  ’collage’  approach  to  course¬ 
ware  is  notable  because  it  tends  to  involve  the  student  more  strongly 
than  other  approaches. 

16.4.1  Pros 

There  are  several  advantages  to  constructing  courseware  with  Hyper¬ 
Writer.  First,  HyperWriter’s  free  runtime  allows  any  courseware  created 
to  be  re-distributed  for  either  free  or  profit.  Second,  HyperWriter’s 
ease  of  use  makes  creating  course-ware  very  simple.  Third,  Hyper¬ 
Writer’s  ability  to  work  with  multiple  forms  of  media  such  as  text, 
graphics  and  video  allows  for  dynamic,  Interesting  applications. 

Finally,  HyperWriter’s  many  navigational  features  make  navigating 
through  HyperWriter  constructed  courseware  easy. 


16.4.2  Cons 


The  most  obvious  disadvantage  to  using  HyperWriter  for  courseware 
applications  is  that  it  has  no  facilities  for  student  evaluation. 
However,  not  all  courseware  requires  this  as  the  Culture  Demo  shows. 

16.5  Application  #5:  Interactive  Questionnaire 

HyperWriter  can  be  used  to  construct  interactive  multiple  choice 
questionnaires.  In  this  application,  a  series  of  links  surrounding  each 
answer  to  a  multiple  choice  question  are  displayed  onscreen.  Whenever  a 
user  clicks  on  an  answer,  a  comment  window  pops  up  to  thank  them  for 
their  response  and  then  prompts  them  to  go  to  the  next  question.  As 
each  question  is  answered,  the  response  is  written  to  an  ASCII  file. 

This  file  can  then  later  be  evaluated  by  the  questioner. 

The  best  way  to  use  this  type  of  application  might  be  to  create  the 
hypertext  questionnaire  and  then  distribute  It  on  floppy  disk  to  the 
different  people  in  the  survey.  At  their  leisure,  they  can  run  the 
application,  answer  the  questions  and  then  return  the  diskette  to  you. 
HyperWriter’ s  ability  to  auto-detect  graphics  screens  and  adjust  to  them 
eliminates  any  worry  that  this  application  might  not  run  on  their 
systems. 

The  demonstration  file  for  this  application  is  HTQUES.HW. 

16.5.1  Pros 

One  outstanding  advantage  with  this  application  Is  that  HyperWriter’s 
runtime  can  be  freely  distributed.  This  means  that  any  questionnaires 
created  In  this  fashion  can  be  distributed  without  royalty  payment.  A 
second  advantage  is  that  with  HyperWriter’s  ^REPORT  command,  ASCII  files 
can  be  created  that  contain  the  results  of  the  questionnaire.  A  third 
advantage  Is  HyperWriter’s  ease  of  use.  Creating  attractive,  interac¬ 
tive  questionnaires  using  HyperWriter  is  quite  easy. 

16.5.2  Cons 

There  are  two  disadvantages  to  this  application.  First,  questionnaires 
are  technically  limited  to  multiple  choice  answers.  One  way  around  this 
Is  to  use  the  Readers  Notes  facility  to  accept  free  input.  A  second 
disadvantage  Is  HyperWriter’s  relatively  simple  reporting  facilities. 

16.6  Application  #6:  Hypertext  Technical  Support  Knowledge  Base 

After  we,  at  NTERGAID,  created  the  MEMO  application,  we  began  to  Iook 
for  other  areas  to  apply  hypertext.  The  second  major  application  we 
constructed  was  called  TECHSPRT  or  Tech  Support.  Tech  Support  is  a 
hypertext  technical  support  knowledge  base.  It  consists  of  a  series  of 
observations  and  comments  on  the  use  of  NTERGAID  products.  It  is 
primarily  built  around  our  original  Black  Magic  product  but  Includes  all 
of  our  other  products.  This  file  is  broken  down  in  two  ways  —  by 
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product  and  then  by  possible  problem  area.  This  lets  our  technical 
support  technicians  solve  problems  quickly  and  easily. 

Although  this  application  is  constructed  as  a  single  document  file  that 
covers  multiple  products,  It  can  just  as  easily  be  constructed  with 
multiple  files.  This  will  allow  much  larger  knowledge  bases  to  be 
constructed. 

The  demonstration  file  for  this  application  is  TECHSPRT.HW. 

16.6.1  Pros 

The  overwhelming  advantage  to  this  application  is  simply  the  advantage 
of  hypertext  itself-the  free  linking  of  information.  This  allows  all 
related  information  to  be  tied  together.  A  second  advantage  is  simply 
the  ease  of  construction.  This  entire  application  was  built  in  a  little 
over  one  night  of  work.  The  time-consuming  part  was  sorting  through  old 
paper  letters  for  material  to  build  the  database  around. 

16.6.2  Cons 

The  major  disadvantage  to  using  HyperWriter  for  technical  support  is 
that  it  isn’t  multi-user  in  nature.  This  means  that  multiple  support 
technicians  can’t  update  the  database  and  make  comments  in  real  time. 

To  get  around  this  problem,  we’ve  adopted  the  following  strategy.  When 
a  new  technical  support  problem  surfaces  or  a  solution  is  found,  that 
solution  is  added  to  the  database  with  the  Readers  Notes  function  and 
then  later  merged  and  relinked  Into  the  master  document.  If  you  were 
constructing  this  application  as  multiple  documents,  you  might  want  to 
use  the  8SUBFILE  and  «MASTERFIIE  commands  to  ensure  that  all  Readers 
Notes  were  exported  simultaneously. 

16.7  Application  #7:  Paper  Replacement 

One  of  the  problems  with  modern  computing  is  the  proliferation  of 
different  text  files.  Every  activity  you  do  with  a  computer  seems  to 
generate  a  text  file  of  one  sort  or  another.  This  is  particularly  acute 
if  you  use  different  online  services  and  maintain  log  files  of  your 
sessions.  Hypertext  can  be  used  to  quickly  and  easily  annotate  these 
files  with  links.  The  files  can  then  be  passed  on  to  co-workers  and 
friends  using  HyperReader.  By  circumventing  printing  out  the  log  files, 
not  only  is  the  step  of  printing  eliminated  but  the  step  of  making 
multiple  copies  for  people  Is  eliminated  also. 

The  demonstration  file  for  this  application  Is  ACTOR. HW.  This  file 
compromises  a  discussion  about  the  ACTOR  (TM)  programming  language  that 
was  downloaded  from  the  WhlteWater  Group  bulletin  board  system.  After 
downloading  the  discussion,  a  series  of  links  were  attached  to  the 
messages  that  clarified  various  points  regarding  Actor.  Then,  once  the 
file  was  annotated,  it  was  distributed  without  the  need  for  printing  it 
out. 
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A  second  approach  to  this  concept  of  paper  replacement  Is  contained  in 
the  file  LITERARY. HW.  This  file  contains  an  English  assignment  along 
with  hypertext  annotation  containing  the  teacher’s  comments. 

16.7.1  Pros 

The  overwhelming  advantage  to  this  application  is  the  cost  saving  from 
not  having  to  print  out  paper  versions  of  documents.  A  second  advantage 
is  that  with  Readers  Notes,  the  readers  comments  can  easily  be  added  to 
documents. 

16.7.2  Cons 

The  disadvantage  to  this  application  is  simply  that  it’s  only  applicable 
to  people  with  computers.  Whereas  paper  is  a  universal  medium,  this  is 
a  medium  limited  only  to  those  people  with  computers. 

16.8  Application  #8:  HyperWrlter  as  a  PIM 

A  new  type  of  software  product  that  has  surfaced  In  the  past  two  years 
is  called  a  Personal  Information  Manager  or  PIM.  A  PIM  is  a  piece  of 
software  that  is  designed  to  mange  miscellaneous  scraps  of  personal  data 
such  as  dates,  times  and  contacts.  Hypertext  can  be  used  to  construct 
an  application  with  many  of  the  features  of  a  PIM. 

Other  applications  that  can  be  constructed  in  the  same  vein  as  a  PIM 
are:  a  personal  database,  phone  call  tracking,  a  personal  time-tracking 
application  and  a  sales  tracking  application. 

The  demonstration  file  for  this  application  Is  HYPERPIM.HW. 

16.8.1  Pros 

There  are  several  advantages  of  using  a  PIM  based  on  a  hypertext 
document.  First,  any  PIM  constructed  with  HyperWrlter  Is  less  costly 
than  specialized  PIM  software.  Second,  there  is  little  to  no  learning 
curve  with  a  HyperWrlter-based  PIM  as  there  Is  with  specialized  PIM 
software.  Third,  any  PIM  constructed  with  HyperWrlter  is  more  flexible 
and  adaptable  than  specialized  PIM  software. 

16.8.2  Cons 

Oesplte  the  above  advantages  of  a  PIM  constructed  with  HyperWrlter, 
there  are  a  number  of  disadvantages  as  well.  To  start,  most  PIMs  have 
calculation  abilities.  They  can  sum  up  expenses,  calculate  dates  and 
more.  HyperWrlter  cannot  handle  these  functions.  Second,  most  PIMs 
have  fairly  flexible  reporting  and  sorting  capabilities.  HyperWrlter  is 
limited  to  a  basic  text  export  and  a  printing  function. 
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16.9  Application  #9:  Presentations 


Unlike  many  presentation  software  packages  on  the  market,  HyperWriter 
has  no  built-in  charting  or  graphics  abilities.  However,  HyperWriter 
can  be  used  to  Integrate  graphics  from  multiple  application  with  its 
screen  grabber  and  .PCX  support.  In  addition,  HyperWriter  can  be  used 
to  construct  very  dynamic  and  interactive  presentations. 

Presentations  have  recently  received  much  attention  from  the  computing 
press  with  several  excellent  articles  being  the  result.  One  outstanding 
article  that  covers  creating  presentations,  although  not  hypertext 
presentations,  appeared  in  February  1989  PC  Computing  magazine.  The 
author  was  Robin  Raskin  and  the  article’s  title  was  "Desktop  Presenta¬ 
tions:  On  With  The  Show."  Additional  articles  on  creating  presenta¬ 
tions  and  the  software  Involved  appeared  In  the  October  17,  1989  PC 
Magazine. 

16.9.1  Pros 

The  greatest  advantage  to  HyperWriter  constructed  presentations  are  the 
dynamic  nature  of  these  presentations.  Not  only  can  HyperWriter 
presentations  use  text  and  graphics  but  they  can  also  use  videodisc 
Images  and  sound.  HyperWriter  is  one  of  the  only  presentation  packages 
that  has  these  multimedia  capabilities.  A  second  advantage  to  Hyper¬ 
Writer  presentations  is  that  relevancy  can  be  added  to  any  part  of  a 
presentation  with  hypertext  links.  With  hypertext  links,  any  part  of  a 
presentation  can  have  more  Information  attached  to  It  for  clarification. 
HyperWriter’ s  many  navigational  abilities  can  be  used  to  find  specific 
information  within  a  presentation.  As  a  presentation  tool,  tours  can  be 
used  to  construct  self-running  versions  of  a  presentation.  Readers 
Notes  can  be  used  by  the  viewer  of  the  presentation  to  add  their  own 
comments  to  the  presentation.  Finally,  HyperWriter’s  free  runtime 
allows  all  presentations  to  be  freely  distributed. 

16.9.2  Cons 

A  main  disadvantage  to  using  HyperWriter  for  presentations  is  Hyper- 
Writer’s  lack  of  charting  capabilities  —  a  key  feature  in  most  presen¬ 
tation  packages.  This  disadvantage  Is  somewhat  lessened  due  to  Hyper- 
Writer’s  ability  to  1mport.PCX  Images.  A  second  disadvantage  Is  that 
HyperWriter  lacks  the  ability  to  automatically  generate  handouts.  To 
some  extent,  this  can  be  addressed  with  HyperWriter’s  printing  capabil¬ 
ities. 

16.10  Application  #10:  Videodisc  Front  End 

HyperWriter  can  be  used  to  construct  interactive,  easy-to-use  front  ends 
to  videodisc  images.  The  example  file,  VIDEO. HW,  is  designed  to  work 
with  National  Gallery  of  Art  Videodisc.  It  presents  a  card  of  informa¬ 
tion  for  selected  works  on  the  videodisc.  Some  of  the  cards  allow  you 
to  "zoom  in"  on  the  images  or  take  a  guided  tour  around  some  of  the 
Images. 
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16.10.1  Pros 


The  advantage  to  this  application  is  that  it  allows  easy  annotating  and 
commenting  on  a  videodisc.  This  addresses  one  of  the  traditional 
objections  to  videodiscs  —  that  they  are  read  only  mediums. 

16.10.2  Cons 

The  disadvantage  to  this  application  is  that  for  each  different  video¬ 
disc  you  have  a  different  front  end  needs  to  be  created.  This  Is  not 
so  much  a  limitation  of  HyperWriter  as  it  is  of  the  videodisc  medium 
itself. 

16.11  Application  nil:  Software  Engineering 

HyperWriter  can  be  used  to  construct  an  environment  for  managing  and 
documenting  large  programming  projects.  In  this  application,  hypertext 
links  are  used  to  create  a  structure  for  viewing  source  code  files. 
HyperWriter’s  ASCII  file  link  is  used  for  this. 

16.11.1  Pros 

There  are  two  major  advantages  to  this  application.  First,  due  to 
HyperWriter’s  ability  to  work  with  extremely  large  ASCII  files,  program¬ 
ming  projects  of  any  size  can  be  managed.  A  second  advantage  is  that 
this  application  addresses  what  critics  have  always  accused  software 
development  of  lacking  —  poor  documentation. 

16.11.2  Cons 

The  disadvantage  to  this  application  is  that  it  must  be  manually 
constructed  for  each  programming  project.  There  are  no  facilities  to 
automatically  build  this  hypertext  structure.  A  second  disadvantage  is 
that  HyperWriter  is  not  multi-user.  This  prevents  multiple  programmers 
from  documenting  their  work  simultaneously. 

16.2  Application  012:  Technical  Documentation 

HyperWriter  can  also  be  used  to  construct  outstanding  technical  documen¬ 
tation.  With  hypertext  links,  documentation  can  be  annotated  and 
explained  at  length  while,  at  the  same  time,  expert  users  can  quickly 
move  past  material  they’re  already  familiar  with. 

The  demonstration  file  for  this  application  Is  HW1CHP1 1 . HW.  This  is 
actually  Chapter  11  of  this  manual  converted  to  a  hypertext  document. 

16.12.1  Pros 

The  main  advantage  to  using  HyperWriter  for  technical  documentation  is 
simply  Its  ability  to  link  Information  together.  A  second  advantage  is 
HyperWriter’s  ability  to  work  with  both  text  and  graphics.  Finally,  any 
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documentation  created  with  HyperWriter  can  be  freely  distributed  with 
HyperWriter’s  runtime. 

16.12.2  Cons 

The  major  disadvantage  of  this  application  isn’t  really  related  to 
HyperWriter  at  all.  It’s  simply  that  people  often  prefer  printed 
documentation  over  online  documentation. 

16.13  Application  #13:  Writing  Environment 

Despite  HyperWriter’s  many  hypertext-specific  features,  it  can  also  be 
sue  quite  successfully  as  no  more  than  a  multi-window  writing  environ¬ 
ment.  Of  course,  it  is  one  of  the  few  such  environments  that  boasts 
hypertext  linking  as  well  as  editing.  A  hypertext  writing  environment 
features  instant  access  to  notes,  sources,  an  outline  and  your  writing 
itself. 

This  type  of  writing  environment  should  be  used  for  the  initial  stages 
of  writing  and  organization.  HyperWriter’s  linking  abilities  can  be 
used  to  help  organize  a  document.  Due  to  HyperWriter’s  limited  printer 
support,  it  is  probably  not  the  best  application  with  which  to  generate 
the  final  essay  or  paper.  Once  most  of  the  writing  and  organizing  is 
done,  HyperWriter’s  export  function  can  be  used  to  move  the  file  into  a 
wordprocessor  or  desktop  publishing  environment  where  the  final  version 
can  be  printed  out. 

16.13.1  Pros 

HyperWriter  is  well  suited  to  this  type  of  application  due  to  its 
linking  abilities  and  its  ability  to  handle  multiple  windows.  In 
addition,  HyperWriter’s  spell  checker  and  full  editor  help  in  writing 
projects. 

16.13.2  Cons 

The  primary  disadvantage  to  this  application  Is  the  need  to  move  the 
information  into  another  program  to  generate  the  final  essay.  A  second 
disadvantage  is  that  HyperWriter  does  not  have  a  thesaurus. 

16.14  Application  #14:  Hypertext  Flash  Cards 

Hypertext  can  also  be  used  to  construct  a  modern  equivalent  to  the  old 
fashioned  flash  card.  A  hypertext  flash  card  application  displays 
something  to  remember  on  a  card  and  then  a  link  from  that  card  to  a 
comment  window  contains  Its  definition  or  description. 

The  demonstration  file  for  this  application  is  called  FCARD.HW.  It 
contains  a  list  of  vocabulary  words  culled  from  The  Handbook  of  College 
Entrance  Examinations  as  well  as  their  definitions.  Two  things  are 
central  to  this  application.  First,  a  screen  background  used  to  create 
the  card  appearance  shown  above.  Second,  in  addition  to  manually  going 
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through  the  cards,  a  constructed  tour  that  displays  each  word,  and  then 
its  definition  was  created.  Using  both  the  tour  and  the  manual  approach 
seems  to  duplicated  the  best  of  quizzing  yourself  with  flashcards  and 
having  someone  quiz  you  with  flashcards. 

A  variant  on  this  application  [can]  be  constructed  that  displayed 
several  alternative  definitions  for  each  word  and  then  gives  feedback  as 
to  the  correct  word  when  each  definition  is  selected.  In  addition,  with 
this  approach,  a  report  file  can  be  generated  containing  the  wrong 
answers. 

16.14.1  Pros 

The  primary  advantage  to  this  application  is  its  ease  of  use.  Not  only 
is  it  extremely  easy  to  use,  but  it  is  also  easy  to  create.  In  addi¬ 
tion,  this  application  can  be  very  useful  for  students. 

16.14.2  Cons 

The  drawback  to  this  application  is  that  HyperWriter  has  no  evaluation 
facilities  to  give  the  user  feedback  as  to  how  he  or  she  does. 

16.15  Application  415:  Electronic  Publishing 

One  area  of  hypertext  that  has  been  slow  to  take  off  is  that  of  elec¬ 
tronic  publishing.  That  is  the  publishing  of  Information  in  a  hypertext 
format.  To  date,  it  seems  that  hypertext  has  been  applied  on  an  in- 
house  basis  but  not  for  wholesale  distribution  of  information.  HapDily, 
this  is  currently  changing.  The  Reg-In-A-Box  application  described 
under  Application  41  and  the  Culture  Document  described  in  Application 
44  are  both  forerunners  of  the  future  of  publishing.  In  an  electronic 
publishing  environment,  documents  are  constructed  designed  to  be  read 
online.  This  allows  them  to  take  full  advantage  of  technologies  such  as 
hypermedia. 

The  demonstration  file  for  this  application  is  called  FCM.HW.  It  is  a 
prototype  of  a  fictional  computer  magazine  constructed  with  hypertext 
links. 

16.15.1  Pros 

The  single  biggest  advantage  of  this  application  is  freedom  from  the 
restraints  of  conventional  publishing.  There  are  less  costs  involved 
and  less  worry  about  the  physical  realities  of  printing  and  distribu¬ 
tion. 

16.15.2  Cons 

The  disadvantage  with  this  application  is  simply  the  lack  of  copyright 
protection  that  the  author  has  over  the  reader.  While  it  is  rare  to  see 
someone  photocopying  an  entire  book,  it  is  not  rare  in  computer  soft¬ 
ware.  To  date,  this  has  been  an  impediment  to  electronic  publishing. 


16.16  Application  #16:  Hypertext  Slide  Show 


Related  to  the  presentation  application  described  previously  is  this 
application,  a  hypertext  slide  show.  Slide  shews  can  be  constructed  in 
two  fashions:  manual  or  automatic.  A  manual  slide  show  is  sequenced 
with  the  rapid  activation  of  links.  An  automatic  slide  show  is  run  with 
a  tour. 

The  file  for  this  application  Is  HTSLIDE.HW.  It  consists  of  both  a 
graphic  and  a  text  version  of  a  slide  show. 

16.16.1  Pros 

The  first  advantage  to  this  application  is  simply  ease  of  use.  A  second 
advantage  is  that  with  HyperWriter’s  runtime,  slide  shows  can  be  freely 
distributed  to  those  who  might  benefit  from  them. 

In  addition,  viewers  of  slide  shows  can  annotate  them  to  give  you 
feedback  —  something  that  no  slideshow  product  on  the  market  supports. 

16.16.2  Cons 

The  one  drawback  to  this  type  of  computer  slide  show  is  HyperWriter’s 
lack  of  specific  transitional  screen  effects.  Some  slideshow  products 
can  change  how  the  screen  is  displayed  when  each  segment  of  the  slide 
show  changes. 

16.17  Application  #17:  Image  Database  of  .PCX  Files 

HyperWriter  can  be  used  to  construct  a  database  of  .PCX  images.  An 
image  database  Is  very  useful  as  it  works  to  eliminate  uncertainty  about 
which  graphic  Images  are  available  on  your  hard  disk. 

The  file  for  this  application  is  IMAGEDB.HW.  It  contains  an  image 
database  organized  along  the  lines  of  a  directory  listing  with  links  for 
keywords  and  a  'DISPLAY’  link  for  each  graphic  image.  A  useful  techni¬ 
que  to  create  this  application  is  using  the  DOS  DIR  command  to  create 
the  file  containing  the  information  about  each  graphics  file.  To  use 
this  technique,  go  to  the  directory  containing  your  .PCX  files  and  type 
the  following: 

Keystroke  Meaning 

DIR  *.PCX  >  PCX. DAT  Do  a  directory  for  all  files  with  an  extension  of 

.PCX  and  pipe  that  directory  into  a  file  called 
PCX. DAT. 

When  the  above  commands  are  given,  no  directory  is  displayed  onscreen. 
Instead,  that  directory  is  written  to  an  ASCII  text  file  that  can  then 
be  imported  into  HyperWriter.  In  addition,  a  macro  or  macros  can  be 
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constructed  that  precisely  format  this  text  file  and  build  the  framework 
of  links  needed  for  this  application. 

Note:  For  reasons  of  size,  only  a  few  images,  those  used  in  the 
presentation  application,  were  used  in  this  application. 

16.17.1  Pros 

One  of  the  advantages  to  this  application  is  that  a  single  HyperWriter 
document  can  hold  references  to  several  hundred  .PCX  files. 

16.17.2  Cons 

The  real  disadvantage  to  this  application  is  the  need  to  update  it  and 
build  links  by  hand.  Much  of  this  effort  can  be  eliminated,  however, 
using  the  DIR  technique  described  above.  A  second  disadvantage  is 
HyperWriter’s  ability  to  handle  only  .PCX  images.  Technically,  an  image 
database  should  handle  multiple  image  formats.  Finally,  HyperWriter 
needs  all  graphics  files  to  be  stored  in  the  same  directory.  One  way 
around  this  is  to  construct  macros  that  change  graphics  directories  in 
HyperWriter. 

16.18  Application  #18:  Text  File  Management 

HyperWriter  can  be  used  to  construct  a  framework  of  links  to  different 
text  files.  In  this  application,  an  outline  structure  of  conferences  on 
an  online  network  is  duplicated  with  links  to  each  part  of  the  discus¬ 
sion  and  the  ASCII  files  that  comprise  the  discussions. 

The  demonstration  file  for  this  application  is  called  BIXTEXT.HW. 

BIXTEXT  is  a  collection  of  different  conferences  downloaded  form  the 
Byte  Information  Exchange  or  BIX  (TM)  computer  network.  These  files 
were  downloaded  and  then  linked  Into  this  framework  of  links. 

Note:  For  legal  reasons,  only  a  very  small  sample  of  text,  primarily 
that  posted  to  BIX  by  NTERGAID,  has  been  shown  here. 

16.18.1  Pros 

There  are  two  major  advantages  to  this  application.  First,  HyperWriter 
can  browse  ASCII  files  of  any  size.  This  means  that  the  ASCII  files  in 
this  application  can  grow  indefinitely  without  worry  of  running  out  of 
memory  in  HyperWriter.  A  second  advantage  is  HyperWriter’s  ability  to 
duplicate  structures  such  as  BIX’s  hierarchy.  This  can  be  used  to 
construct  a  very  visual  approach  to  text  file  management  —  something 
that  is  normally  quite  obtuse. 

16.18.2  Cons 

The  disadvantage  of  this  application  is  that  while  hypertext  links  form 
the  framework  for  this  application,  they  can  only  be  created  to  the  text 
files  -  not  from  the  text  files.  This  limits  some  of  the  hypertext 
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functionality  of  this  document.  Although  this  application  does  not 
demonstrate  it,  there  is  no  reason  why  links  to  very  specific  items  in 
each  file  could  not  be  constructed.  This  would  regain  some  of  the  power 
of  hypertext  linking  for  this  application.  A  second  disadvantage  of 
this  application  is  the  lack  of  a  powerful  search  command  when  viewing 
the  ASCII  files. 

16.19  Application  #19:  Computer  Based  Training 

Despite  hypermedia’s  myriad  uses,  the  application  of  hypermedia  to 
Computer  Based  Training  (CBT)  stands  out.  A  hypermedia  system  such  as 
HyperWriter  is  an  ideal  platform  for  constructing  CBT  applications.  One 
particular  HyperWriter  feature  applicable  to  CBT  is  that  of  tours. 

16.19.1  Pros 

One  of  HyperWriter’s  chief  advantages  as  a  CBT  tool  is  that  any  applica¬ 
tion  created  with  HyperWriter  can  be  freely  distributed  with  Hyper¬ 
Writer’s  runtime.  A  second  advantage  is  that  with  HyperWriter’s  Readers 
Notes  feature,  students  can  take  notes  on  the  CBT  application  if  they 
desire.  A  final  advantage  is  simply  that  HyperWriter  makes  it  very  easy 
to  get  applications  up  and  running  quickly. 

16.19.2  Cons 

As  with  the  courseware  example  discussed  in  Section  16.4,  the  chief 
disadvantage  to  this  is  that  HyperWriter  has  no  evaluation  facilities. 
This  prevents  HyperWriter  from  offering  students  evaluations  of  their 
progress. 

16.20  Additional  Applications 

While  the  above  application  profiles  are  somewhat  exhaustive,  it  merely 
scratches  the  surface  of  how  HyperWriter  can  be  applied.  Some  addition¬ 
al  applications  for  HyperWriter  are- 

-  Case  Analysis 

-  Interactive  Kiosks 

-  Recipe  Management 

-  Knowledge  Work 

-  Easy-To-Use  Front  Ends  to  Simulation  Programs 

-  Executive  Information  Systems 

16.21  Conclusion 

Although  some  of  the  applications  in  this  chapter  may  seem  a  bit 
extreme,  they  do  demonstrate  the  versatility  and  power  of  hypertext. 
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These  application  bear  out  the  point  covered  in  Chapter  14:  Nearly 
anything  can  be  done  with  hypertext  —  it  only  takes  imagination. 

16.22  Summary 

HyperWriter  can  be  applied  to  almost  any  problem  involving  information 
management.  These  applications  can  range  from  technical  support  to 
replacing  paper.  The  key  to  applying  HyperWriter  to  these  diverse 
problems  is  imagination. 
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Appendix  C:  List  of  the  Effects  that  Matter  in  Hypertext 


Phenomenon  studied  %  Difference 


1.  Effect  of  age  on  moving  from  just  looking  at  a  hypertext 
system  to  actually  using  it: 

Young  (<20  years)  vs.  older  users  relative  to  on-lookers  115 

2.  Effect  of  users’  motivation,  activity  level,  etc.  on  number 
of  new  nodes  created: 

Most  active  participant  vs.  modal  participant  on  subnet  A  100 

3.  Effect  of  users’  motivation,  activity  level,  etc.  on  number 
of  new  nodes  created: 

Most  active  participant  vs.  modal  participant  on  subnet  B  63 

4.  Proportion  of  effort  spent  attending  to  the  medium  itself 
rather  than  on  solving  task: 

Revising  text  on  computer  vs.  with  pen  and  paper  61 

5.  Subjective  preconceptions: 

Online  fiction  vs.  printed  fiction  42 

6.  Effect  of  level  of  expertise  on  approach  to  solving  task: 

Use  of  table  of  contents  on  third  day  vs.  first  day  40 

7.  Touch  screen  activation  strategies  in  Hyperties: 

Take-off  vs.  land-on  activation,  blank  space  errors  34 

8.  Effect  of  user’s  task  on  choice  of  navigation  mechanism: 

Use  of  guided  tour  mechanism,  exploratory  vs.  directed  task  34 

9.  Hypertext  vs.  command-based  database  access: 

Spikes  (user  retracing  route  through  data  by  backtracking)  32 

10.  Effect  of  user’s  task  on  choice  of  navigation  mechanism: 

Use  of  index,  exploratory  vs.  directed  task  30 

11.  Issue-based  argumentation  networks  built  in  gIBIS: 

Links  "supporting”  position  vs.  links  "objecting  to"  24 

12.  SuperBook  vs.  printed  book: 

"Discriminating"  facts  Included  23 

13.  Hypertext  vs.  command-based  database  access: 

Rings  (user  returning  to  a  previously  visited  piece  of  data)  22 

14.  Effect  of  screen  size:  Time  to  answer  questions: 

120  lines  vs.  22  lines,  text  editor  with  program  text  21 

15.  Hypertext  vs.  command-based  database  access: 

Proportion  of  different  nodes  visited  to  total  nodes  visited  20 

16.  Effect  of  fast  (3  sec.)  vs.  slow  (11  sec.)  response  times: 

time  to  complete  task  20 

17.  Hierarchical  hypertext  vs.  linear  text  file: 

Users’  subjective  preference  20 


(58:245) 
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Appendix  D:  Questions  Asked  MAJCOMS 


1.  Who  is  the  individual  at  (MAJCOM)  who  handles  economic  analysis  (EA)? 

2.  What  is  th-  major  type  of  EA  performed?  (i.e.  MFH,  MCP,  MMHS) 

3.  What  reference  documents  do  you  recommend  using  to  complete  an  EA?  (regs, 
guidebooks,  base  level  cost  hand  book,  AFSC  cost  estimating  handbook,  army 
pubs,  policy  letters,  checklists,  software  programs) 

4.  Are  different  references  used  depending  upon  the  EA  type? 

5.  Who  (at  base  level)  performs  EAs?  (i.e.  ACC,  CE,  LGS,  etc) 

6.  Is  preparer’s  knowledge  base  (on  EAs)  different?  (basic  vs  advanced) 

7.  What  are  the  most  common  problem  areas  found  in  EAs?  (discounting, 
documentation,  methodology,  sources) 

8.  Are  any  of  the  above  reference  documents  available  in  computerized  form? 
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Appendix  E:  Hypertext  Systems 


System 

Address 

Phone 

Hyperties 

Cognetics  Corp  (55  Princeton-Hlghtstown  Rd, 
Princeton  Junction,  NY  08550) 

609-799-5005 

Fi leVisionV 

Marvel  In  Corp  (3420  Ocean  Park  Blvd, 

Suite  3020,  Santa  Monica,  CA  90405) 

213-450-6813 

Oocument 

Examiner 

Symbolics,  Inc  (  11  Cambridge  Center, 
Cambridge,  MA  02142) 

617-621-7500 

Text  KRS 
(Knowledge 
Retrieval 
System) 

KnowledgeSet  Corp  (60  Garden  Court, 

Building  A,  Monterey,  CA  93940) 

415-968-9888 

Guide 

Owl  International,  Inc  (14218  Northeast 

21st  St,  Bellevue,  WA  98007) 

800-344-9737 
or  206-747- 
3203 

HyperCard 

Apple  Computer,  Inc  (20525  Mariani  Ave, 
Cupertino,  CA  95014) 

408-996-1010 

KMS 

(Knowledge 
Management 
System 1 

Scribe  Systems,  Inc  (Commerce  Court,  Suite 
240,  4  Station  Square,  Pittsburgh,  PA  15219) 

412-281-5959 

Knowledge 

Pro 

Knowledge  Garden,  Inc  (473A  Malden  Bridge 

Rd,  Nassua,  NY  12123) 

518-766-3000 

HyperPad 

Brightbi 1 1-Roberts  (120  East  Washington  St, 
Suite  421,  Syracuse,  NY  13202) 

315-474-3400 

Superbook 

Bell  Communications  Research  (Bellcore) 

(435  South  St,  Morristown,  NJ  07962) 

201-829-2000 

201-740-6110 
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Appendix  F:  Questions  for  Testing  and  Validating  Prototype 


Please  rate  the  questions  according  to  the  following  scale: 

1  -  strongly  agree 

2  -  agree 

3  -  neutral 

4  -  disagree 

5  -  strongly  disagree 
N  -  not  applicable 


1.  I  consider  myself  knowledgeable  about  general  computer  operation. 

1  2  3  4  5  N 

2.  I  ran  the  prototype  from: 

hard  disk  floppy  disk 

3.  I  had  no  problems  installing  the  software  onto  my  computer. 

1  2  3  4  5  N 

4.  The  opening  screen  of  the  prototype  was  self  explanatory. 

1  2  3  4  5  N 

5.  The  opening  screen  instructions  allowed  me  to  activate  links. 

1  2  3  4  5  N 

6.  I  used  the  reference  system  help.  yes  no 

(if  no,  skip  to  question  7) 

a.  After  reviewing  the  general  help  I  felt  confident  using 
the  prototype. 

1  2  3  4  5  N 


b.  I  reviewed  the  advanced  help  screens  yes  no 

(If  no,  skip  to  question  6d). 

c.  The  advanced  help  screens  were  self  explanatory. 

1  2  3  4  5  N 


d.  With  the  online  help  a  users  manual  is  not  required. 
1  2  3  4  5  N 


7. 


I  found  the  following  control 

a.  map  function 

b.  tours  function 

c.  TOC 

d.  index  function 

e.  note  function 

f.  past  history  function 

g.  hypertext  help  function 


panels  useful: 

1  2  3  4  5  N 
1  2  3  4  5  N 
1  2  3  4  5  N 
1  2  3  4  5  N 
1  2  3  4  5  N 
1  2  3  A  5  N 
1  2  3  4  5  N 


8.  This  system  was  easy  to  learn. 


1  2  3  4  5  N 
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9.  The  system  was  easy  to  use. 


1  2  3  4  5  N 


10.  I  got  lost  (i.e.,  was  not  sure  where  I  was  within  the  document). 

1  2  3  4  5  N 

11.  The  topics  presented  in  the  table  of  contents  were  appropriate. 

1  2  3  4  5  N 


12.  This  system  would  help  me  find  information  more  easily. 

1  2  3  4  5  N 

13.  This  system  would  be  useful  as  an  office  reference  system. 

1  2  3  4  5  N 


5  N 
5  N 
5  N 
5  N 
5  N 


14.  This  system  would  be  useful  in  economic  analysis  for: 


a. 

first  time  learning  of  concepts 

1  2 

3 

4 

b. 

browse  for  general  information 

1  2 

3 

4 

c. 

looking  up  the  answer  to  a  specific  question 

1  2 

3 

4 

d. 

research  purposes 

1  2 

3 

4 

e. 

review  of  previously  familiar  material 

1  2 

3 

4 

15.  In  my  normal  job,  it  would  have  taken  me  more  time  to  research 
an  equivalent  amount  of  information  using  any  sources  (i.  e., 
paper  documents,  coworkers,  etc). 

1  2  3  4  5  N 

16.  For  the  amount  of  time  spent,  I  could  learn  more  with  this 
system  than  using  any  of  the  sources  above,  (i.  e.,  paper 
documents,  coworkers,  etc). 

1  2  3  4  5  N 


17.  If  I  had  this  system  on  my  desk  (or  a  similar  hypertext 
system  in  my  functional  area),  I  would  expect  to  use  it: 

a.  several  times  a  day 

b.  once  or  twice  a  day 

c.  once  or  twice  a  week 

d.  once  or  twice  a  month 

e.  less  than  once  a  month 


18.  The  features  I  liked  about  the  system: 

(You  may  select  more  than  one  response) 

a.  displays  (use  of  color,  screen  organization,  contextual  info). 

b.  functions  (what  things  you  can  do  with  the  system). 

c.  data  links  (how  you  get  from  one  place  in  the  text  to  another). 

d.  speed  of  processing  (how  fast  the  computer  does  things). 

e.  Instructions  (on  how  to  use  the  system). 

f.  data  (the  text  used  in  the  system). 

g.  depth  and  breadth  of  data  available. 

h.  help  (on-line  instructions). 
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19.  The  following  features  of  the  system  need  to  be  improved: 

(You  may  select  more  than  one  response) 

a.  displays  (use  of  color,  screen  organization,  contextual  info). 

b.  functions  (what  things  you  can  do  with  the  system). 

c.  data  links  (how  you  get  from  one  place  in  the  text  to  another). 

d.  speed  of  processing  (how  fast  the  computer  does  things). 

e.  instructions  (on  how  to  use  the  system). 

f.  data  (the  text  used  in  the  system), 
h.  depth  and  breadth  of  data  available. 

g.  help  (on-line  instructions). 

20.  I  used  the  reference  system  for: 

a.  less  than  30  minutes. 

b.  30  minutes  to  one  hour. 

c.  one  to  two  hours. 

d.  more  than  two  hours. 

21.  If  you  have  any  other  general  comments,  please  record  them  on  a  separate 
sheet  of  paper. 

(54:56;  71:397-407;  80) 
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Typical  Applications:  Interactive,  hypermedia  and  multimedia  documents  such 

as  Presentations,  Computer  Based  Training  Guides, 
Technical  Documentation,  Educational  Courseware  and 
Electronic  Publishing. 


Hardware  Required: 


Computer: 


Graphics  Card: 
Printer: 


Input: 

Video  Disc  Players: 
Digitized  Sound: 


IBM  PC,  XT,  AT  or  PS/2  or  Compatible.  2  Floppy  drives 
minimum,  Hard  disk  recommended,  384k  memory,  640k 
recommended. 

CGA,  HGA,  EGA,  or  VGA  cards.  Character  graphics  mode 
also  supported. 

IBM  Proprinter  and  Epson  compatible  dot  matrix 
printers,  Hewlett  Packard  Laser  Jet.  For  additional 
printer  support,  software  tools  to  create  your  own 
printer  drivers  are  included. 

Cursor  Keys  or  Mouse  (Microsoft,  Logitech  or  com¬ 
patible)  . 

Sony  LDP-2000  series.  Pioneer  LDV-4200  series.  Tools 
to  create  drivers  for  other  Video  Disc  players  are 
Included. 

Digitized  sound  via  Covox’s  Speech  Thing  and  Sound 
Master  is  supported.  This  requires  an  optional  speaker 
which  can  be  purchased  for  $29.95.  In  addition,  a 
’PLAY’  command  is  included  in  the  script  language  for 
sound  using  the  PC’s  speaker. 


Price:  $299.95  including  documentation. 


Abilities:  HyperWriter  is  a  general  purpose  hypermedia  authoring  tool  that 

can  be  used  to  create  multimedia  documents  fusing  text,  bitmapped 
graphics,  digitized  sound,  and  video  disc  images.  Different 
media  types  are  tied  together  using  hypertext  links. 


Links:  Hypertext  links  can  be  formed  both  to  and  from  text  and  graphics. 
Links  can  also  be  created  to  sound  and  video  disc  images.  HyperWriter 
supports  three  classes  of  links:  Text,  Graphic  and  Action.  The  subclasses 
of  the  text  link  are  Jump  (cross  reference),  SWAP  (text  replacement), 
Comment  (pop  up  window)  and  ASCII  (browse  external  files).  The  subclasses 
of  the  graphic  link  give  control  over  how  images  are  to  be  displayed.  The 
subclasses  of  the  Action  link  are  DOS  (run  DOS  programs),  Menu  (activate 
menu  functions)  and  Script  (write  program  scripts).  The  script  subclass  is 
used  for  controlling  video  disc  Images,  digitized  sound  and  generation  of 
reports.  Scripts  can  also  be  attached  to  any  link  type  to  allow  for 
execution  of  an  action  when  the  link  is  activated. 


Link  Attributes:  HyperWriter  stores  attributes  of  links  such  as  author, 
password,  date  and  more. 


Document  Length  and  Content:  Documents  can  be  as  large  as  available  RAM. 
Also,  document  files  can  be  linked  together  on  disk  giving  virtually 
unlimited  storage. 

Document  Structure:  Any  document  structure  can  be  created  in  HyperWriter. 
It  places  no  restrictions  on  the  authoring  process.  Links  can  be  formed  to 
both  new  and  previously  existing  materials. 

Authoring:  HyperWriter  includes  a  full-featured  text  editor  for  document 
creation.  Existing  files  cal  also  be  imported.  Link  making  in  HyperWriter 
is  freeform  and  similar  to  editing  functions  such  as  Cut,  Copy  and  Paste. 
Links  are  created  by  first  marking  a  link  anchor,  then  specifying  the  type 
of  link  and  finally  entering  the  material  for  the  destination  of  the  link. 

A  link  mimicking  feature  allows  previously  created  links  to  be  duplicated 
with  minimal  overhead.  To  create  documents  using  video  disc  images,  a 
video  disc  scripting  language  is  used. 

User  Interface:  HyperWriter  uses  a  pull  down  menu  interface  with  dialog 
boxes.  Control,  Alt  and  Function  keys  are  also  supported  for  quicker  use. 
The  user  interface,  both  menus  and  dialog  boxes,  can  be  controlled  either 
with  the  mouse  or  keyboard.  Scroll  bars  automatically  appear  if  the 
contents  of  a  window  in  a  document  stretch  past  the  window  boundary. 

Scripting  Language:  A  limited  scripting  language  provides  for  directly 
controlling  the  video  disc  access,  control  of  sound  files  and  use  of  a  play 
command  (for  digital  sound  effects).  Additional  scripting  commands  allow 
such  things  as  a  ’Select  Box’  which  queries  a  user  for  the  destination  of  a 
link. 

Background  Screens:  To  support  card  metaphor  hypertext  documents  similar 
to  HyperCard  (TM),  multiple  backgrounds  using  both  text  and  graphics  are 
allowed  per  document. 

File  Format:  HyperWriter  uses  an  internally  developed  .HW  file  format. 

This  format  is  extendable  to  different  media  types  beyond  those  supported 
in  the  initial  release.  An  Integral  part  of  this  file  format  is  data 
compression  and  encryption  to  ensure  that  documents  are  stored  as  compactly 
as  possible.  Specifications  for  the  file  format,  as  well  as  a  toolkit  for 
using  it,  will  be  released  in  early  1990. 

Navigational  Tools:  Graphic  map  browser,  Global  text  search,  Goto  window 
command,  Bookmarks,  Collapse  document  command,  Temporary  markers,  and 
Dynamic  tours  of  documents. 

Compatibi 1 itv:  HyperWriter  can  load  hypertext  documents  created  with  our 
Black  Magic  hypertext  authoring  system. 

Formatting  Tools:  Text  coloring,  Justification,  Bold  Facing,  Italicizing, 
Margins,  Tabs,  Text  centering,  Support  for  extended  ASCII  character  set, 
Removal  of  carriage  returns  for  Imported  files. 
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Additional  Feature:  Macro  recorder;  Screen  Grabber  provided  for  graphics 
integration;  Reporting  capabilities  based  on  link  activation;  Import  and 
Export  of  ASCII  Files. 

Document  Distribution:  Included  Public  Domain  Runtime  provides  unlimited 
distribution  rights  for  any  documents  that  you  create.  The  runtime  has 
virtually  all  of  the  features  of  the  authoring  system  except  those  of 
altering  documents.  In  addition,  the  runtime  supports  annotation  of 
documents. 

Supported  File  Formats:  ASCII  for  text  files.  .PCX  files  for  bitmapped 
graphics.  Also  supported  is  the  .MGR  format  of  the  included  screen 
grabber. 

(60:1-2) 
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Appendix  H:  Prototype  Test  Results 

Questions  were  rated  according  to  the  following  scale: 

1  -  strongly  agree  4  -  disagree 

2  -  agree  5  -  strongly  disagree 

3  -  neutral  N  -  not  applicable 


Testers  were  divided  into  two  categories  based  on  their  answer  to  question 
one,  inexperienced  computer  users  (ratings  3,  4,  5,  and  N)  and  experienced 
computer  users  (ratings  1  and  2).  The  numbers  show  the  number  of  individuals 
who  gave  the  indicated  rating.  The  numbers  in  parenthesis  ()  are  percentages 
of  the  of  the  total  number  per  category.  Ratings  of  "not  applicable”  were  not 
considered  (other  than  question  one)  in  the  counts  or  in  the  percentages. 


1 . 


consider  myself  knowledgeable 

about 

general 

computer 

operation. 

1 

2 

3 

4 

5  N 

26(46) 

24(42) 

3(5) 

2(4) 

2(4) 

2.  I  r*n  the  prototype  from: 

hard  disk  54(95) 

floppy  disk  3(5) 


3.  I  had  no  problems 

Inexperienced  User 
Experienced  User 
Total 

4.  The  opening  screen 

Inexperienced  User 
Experienced  User 
Total 


installing  the  softwa 
1  2 

3(43)  2(29) 

33(66)  14(28) 

36(63)  16(28) 

of  the  prototype  was 
1  2 

2(33)  4(67) 

20(41)  17(35) 

22(40)  21(38) 


e  onto  my  computer. 

3  4  5 

1(14)  1(14) 

1(2)  1(2)  1(2) 

1(2)  2(4)  2(4) 

self  explanatory. 

3  4  5 

6(12)  4(8)  2(4) 

6(11)  4(7)  2(4) 


links. 
5 

2(4) 
2(4) 

6.  I  used  the  reference  system  help. 

yes  no 

Inexperienced  User  7(100) 

Experienced  User  41(82)  9(18) 

Total  48(84)  9(16) 


5.  The  opening  screen  instructions  allowed  me  to  activate 

12  3  4 

Inexperienced  User  3(43)  4(57) 

Experienced  User  19(40)  22(46)  3(6)  2(4) 

Total  22(40)  26(47)  3(5)  2(4) 


a.  After  reviewing  the  general 
the  prototype. 

1 

Inexperienced  User 
Experienced  User  8(20) 

Total  8(17) 


help  I  felt  confident  usi 


2 

18(44) 

18(38) 


3 

2(29) 

10(24) 

12(25) 


4 

5(71) 

4(10) 

9(19) 


ng 

5 

1(2) 

1(2) 
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b.  I  reviewed  the  advanced  help  screens 


yes  no 

Inexperienced  User  5(71)  2(29) 
Experienced  User  27(57)  20(43) 
Total  32(59)  22(41) 


c.  The  advanced  help  screens  were  self  explanatory. 


1 

2 

3 

4 

Inexperienced  User 
Experienced  User 

9(33) 

14(52) 

2(40) 

3(11) 

3(60) 

1(4) 

Total 

9(28) 

14(44) 

5(16) 

4(13) 

d.  With  the  online  help 

a  users 

manual 

is  not  required. 

1 

2 

3 

4 

Inexperienced  User 
Experienced  User 

3(10) 

1(14) 

9(29) 

9(29) 

3(43) 

10(32) 

Total 

3(8) 

10(26) 

9(24) 

13(34) 

I  found  the  following  control 

panels  useful: 

1 

2 

3 

4 

a.  map  function 

Inexperienced  User 

1(14) 

1(14) 

4(57) 

1(14) 

Experienced  User 

9(20) 

18(40) 

7(16) 

8(18) 

Total 

10(19) 

19(37) 

11(21) 

9(17) 

b.  tours  function 

Inexperienced  User 
Experienced  User 

1(17) 

7(15) 

20(43) 

5(83) 

10(21) 

10(21) 

Total 

8(15) 

20(38) 

15(28) 

10(19) 

c.  TOC 

Inexperienced  User 

1(20) 

2(40) 

2(40) 

Experienced  User 

14(30) 

27(57) 

6(13) 

Total 

15(292 

29(56) 

8(15) 

d.  index  function 

Inexperienced  User 
Experienced  User 

6(18) 

12(35) 

4(100) 

10(29) 

5(15) 

Total 

6(16) 

12(32) 

14(37) 

5(13) 

e.  note  function 

Inexperienced  User 
Experienced  User 

3(50) 

10(22) 

3(50) 

18(40) 

11(24) 

6(13) 

Total 

13(25) 

21(41) 

11(22) 

6(12) 

f.  past  history  function 

Inexperienced  User 
Experienced  User 

3(8) 

9(23) 

5(83) 

9(23) 

15(38) 

Total 

3(7) 

9(20) 

14(31) 

15(33) 

5 


5 

3(43) 

3(8) 


5 


3(7) 

3(6) 


1(3) 

1(3) 


1(17) 

3(8) 

4(9) 


g. 

hypertext  help  function 

Inexperienced  User 

2(33) 

4(67) 

Experienced  User 

10(23) 

22(51) 

8(19) 

3(7) 

Total 

10(20) 

24(49) 

12(24) 

3(6) 

8. 

This  system  was  easy  to  learn. 

1 

2 

3 

4 

5 

Inexperienced  User 

1(14) 

1(14) 

5(71) 

Experienced  User 

13(26) 

24(48) 

5(10) 

7(14) 

1(2) 

Total 

13(23) 

25(44) 

6(11) 

12(21) 

1(2) 

9. 

The  system  was  easy 

'  to 

use. 

1 

2 

3 

4 

5 

Inexperienced  User 

2(29) 

3(43) 

2(29) 

Experienced  User 

12(24) 

22(44) 

9(18) 

6(12) 

1(2) 

Total 

12(21) 

24(42) 

12(21) 

8(14) 

1(2) 

10. 

I  got  lost  ( 1 . e. , 

was 

not  sure 

where 

I  was  within  the  document) 

1 

2 

3 

4 

5 

Inexperienced  User 

1(14) 

3(43) 

3(43) 

Experienced  User 

4(8) 

11(22) 

5(10) 

20(40) 

10(20) 

Total 

5(9) 

14(25) 

5(9) 

23(40) 

10(18) 

11. 

The  topics  presented 

in  the  table  of 

contents 

were  appropriate. 

1 

2 

3 

4 

5 

Inexperienced  User 

4(67) 

1(17) 

1(17) 

Experienced  User 

8(16) 

33(67) 

6(12) 

2(4) 

Total 

8(15) 

37(67) 

7(13) 

3(5) 

12. 

This  system  would 

help  me  find 

information  more  easily 

1 

2 

3 

4 

5 

Inexperienced  User 

1(14) 

4(57) 

1(14) 

1(14) 

Experienced  User 

16(32) 

26(52) 

2(4) 

5(10) 

1(2) 

Total 

17(30) 

30(53) 

3(5) 

6(11) 

1(2) 

13. 

This  system  would 

be 

useful  as 

an  office  reference  system. 

1 

2 

3 

4 

5 

Inexperienced  User 

1(17) 

2(33) 

2(33) 

1(17) 

Experienced  User 

18(36) 

23(46) 

4(8) 

3(6) 

2(4) 

Total 

19(34) 

25(45) 

6(11) 

3(5) 

3(5) 

14. 

This  system  would 

be 

useful  in 

economic  analysis  for: 

1 

2 

3 

4 

5 

a. 

first  time  learning  of  concepts 

Inexperienced  User 

2(29) 

3(43) 

2(29) 

Experienced  User 

9(18) 

25(50) 

5(10) 

8(16) 

3(6) 

Total 

11(19) 

28(49) 

7(12) 

8(14) 

3(5) 

b. 

browsing  for  general 

information 

Inexperienced  User 

2(29) 

4(57) 

1(14) 

Experienced  User 

14(28) 

25(50) 

8(16) 

3(6) 

Total 

16(28) 

29(51) 

9(16) 

3(5) 
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c.  looking  up  the  answer  to  a  specific  question 


Inexperienced  User 

1(17) 

3(50) 

2(33) 

Experienced  User 

11(22) 

15(31) 

17(35) 

5(10) 

1(2) 

Total 

12(22) 

18(33) 

19(35) 

5(9) 

1(2) 

d.  research  purposes 

Inexperienced  User 

2(33) 

3(50) 

1(17) 

Experienced  User 

9(18) 

18(37) 

14(29) 

7(14) 

1(2) 

Total 

9(16) 

20(36) 

17(31) 

7(13) 

2(4) 

e.  review  of  previously  familiar 

material 

Inexperienced  User 

5(83) 

1(17) 

Experienced  User 

17(35) 

25(52) 

5(10) 

1(2) 

Total 

17(31) 

30(56) 

6(11) 

1(2) 

15.  In  my  normal  job,  it  would  have  taken  me  more  time  to  research 
an  equivalent  amount  of  information  using  any  sources  (1.  e., 
paper  documents,  coworkers,  etc). 


1 

2 

3 

4 

5 

Inexperienced  User 

1(17) 

3(50) 

2(33) 

Experienced  User 

16(32) 

22(44) 

8(16) 

2(4) 

2(4) 

Total 

17(30) 

25(45) 

8(14) 

4(7) 

2(4) 

».  For  the  amount  of  time 

spent, 

I  could 

learn  more  with 

this 

system  than  using  any 

of  the  sources  above.  1 

. i .  e. , 

paper 

documents,  coworkers, 

etc). 

1 

2 

3 

4 

5 

Inexperienced  User 

1(17) 

3(50) 

2(33) 

Experienced  User 

14(29) 

20(41) 

9(18) 

4(8) 

2(4) 

Total 

15(27) 

23(42) 

9(16) 

6(11) 

2(4) 

’.  If  I  had  this  system  on  my  desk  (or  a 

similar  hypertext 

system  in  my  functional  area), 

I  would 

expect 

to  use 

it: 

Inexp 

Exp 

Total 

a.  several  times  a  day 

1(17) 

11(22) 

12(22) 

b.  once  or  twice  a  day 

2(33) 

10(20) 

12(22) 

c.  once  or  twice  a  week 

3(50) 

17(35) 

20(36) 

d.  once  or  twice  a  month 

8(16) 

8(15) 

e.  less  than  once  a  month 

3(6) 

3(5) 

18.  The  features  I  liked  about  the  system: 

(Note:  Percentages  for  questions  18  and  19  are  calculated  based  upon  the 
fact  that  each  individual  could  select  any  number  of  items.  Inexperienced 
percentages  are  based  on  a  total  possible  of  7  and  experienced  are  based  on  a 
total  of  50) 

Inexp  Exp  Total 

a.  displays  (use  of  color,  screen  2(29)  19(38)  21(37) 

organization,  contextual  Info). 

b.  functions  (what  things  you  can  do  4(57)  26(52)  30(53) 
with  the  system). 
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c. 

data  links  (how  you  get  from  one 
place  in  the  text  to  another). 

2(29) 

38(76) 

40(70) 

d. 

speed  of  processing  (how  fast 
the  computer  does  things). 

1(14) 

29(58) 

30(53) 

e. 

instructions  (on  how  to  use  the 
system). 

6(12) 

6(11) 

f. 

data  (the  text  used  in  the 
system) . 

3(43) 

12(24) 

15(26) 

g- 

depth  and  breadth  of  data 
available. 

2(29) 

12(24) 

14(25) 

h. 

help  (on-line  instructions). 

1(14) 

15(30) 

16(28) 

i. 

The  following  features  of  the  system  need  to 

be  improved: 

Inexp 

Exp 

Total 

a. 

displays  (use  of  color,  screen 
organization,  contextual  info). 

3(43) 

12(24) 

15(26) 

b. 

functions  (what  things  you  can  do 
with  the  system). 

8(16) 

8(14) 

c. 

data  links  (how  you  get  from  one 
place  in  the  text  to  another). 

4(57) 

6(12) 

10(18) 

d. 

speed  of  processing  (how  fast 
the  computer  does  things). 

1(14) 

3(6) 

4(7) 

e. 

instructions  (on  how  to  use  the 
system) . 

5(71) 

28(56) 

33(58) 

f. 

data  (the  text  used  in  the 
system). 

7(14) 

7(12) 

9- 

depth  and  breadth  of  data 
available. 

3(43) 

14(28) 

17(30) 

h. 

help  (on-line  instructions). 

2(29) 

14(28) 

16(28) 

1. 

I  used  the  reference  system  for: 

Inexp 

Exp 

Total 

a. 

less  than  30  minutes. 

2(29) 

19(39) 

21(38) 

b. 

30  minutes  to  one  hour. 

4(57) 

28(57) 

32(57) 

c. 

one  to  two  hours. 

1(14) 

2(4) 

3(5) 

d. 

more  than  two  hours. 

100 


Appendix  I:  Instructions  to  Run  Prototype 


Use  the  instructions  below  to  run  the  prototype. 

a.  If  you  are  running  the  system  from  a  hard  disk  drive:You  will  be 
given  one  disk  with  a  file  called  INSTALL.EXE.  To  install  the  program,  make  a 
subdirectory  called  HR  on  the  C  drive  and  copy  the  file  into  it.  Install  the 
reference  system  by  typing  INSTALL.  You  need  approximately  380K  of  free  disk 
space.  Begin  the  prototype  by  typing  START. 

(Note:  If  you  are  using  another  drive  or  subdirectory  name,  the  first  four 
lines  of  the  HR. INI  file  must  be  modified  (after  installing)  to  reflect  the 
correct  path.  To  do  this,  edit  the  file  with  WordPerfect,  Ted,  EDLIN,  etc  and 
save  as  ASCII  format.) 

b.  If  you  need  to  run  the  system  from  a  dual  floppy  drive  let  me  know, 
I’ll  provide  you  with  two  disks  to  use. 
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1.  Installation/Evaluation 

a.  I’m  not  sure  if  I  Installed  my  software  incorrectly,  but  the 
first  screen  that  come  up  for  me  was  a  blank  one  except  for  a  couple  of 
numbers  in  the  corner.  After  pressing  a  few  keys  I  got  a  menu.  I 
played  around  in  there  for  a  while  and  read  most  of  the  help  section.  I 
wasn’t  sure  exactly  what  was  meant  by  the  term  link  in  this  software  and 
I  couldn’t  find  where  it  was  explained.  Finally  I  chose  the  right  key 
to  bring  up  your  prototype.  This  helped  me  to  understand  what  the 
system  was  supposed  to  do  (up  to  that  point  I  had  no  idea).  More 
instructions  telling  us  what  menus  to  use  to  bring  up  the  prototype  and 
a  basic  explanation  of  the  software  package  would  have  saved  a  lot  of 
time. 

b.  I  really  didn’t  understand  what  it  was  I  was  evaluating.  Maybe 
some  more  in-depth  Instructions  as  to  what  it  is  this  thing  is  supposed 
to  do  and  who  is  supposed  to  use  it,  I  would  be  able  to  evaluate  it 
better. 

c.  Your  letter  notwithstanding,  it’s  very  difficult  to  separate 
the  bugs  in  the  development  software  from  your  program.  Frequent 
lockups  were  very  irritating.  Telling  users  to  ignore  these  problems 
does  not  eliminate  their  subconscious  impact. 

2.  Instructions  on  how  to  use  the  Prototype 

a.  Explain  the  F10  key  (menu  option)  on  the  cover  screen.  Need  a 
key  template  for  the  menu  function  keys. 

b.  A  users  note  would  be  helpful  in  some  instances  since  some  of 
the  help  notes  were  cryptic  at  times.  Look  at  other  software  screens  to 
determine  help  notes  that  should  be  on  the  screen  (e.g.,  on  the  opening 
screen  instructions  say  "Press  the  Function  Key  FI  to  activate  links” 
and  "To  return  from  link  press  ESC".  It  would  be  better  to  say  "FI 
Activate  Link,  ESC  Return  from  Link".) 

c.  Didn’t  mention  mouse  capability.  It  was  not  hard  to  figure  out 
how  to  run  the  program  with  a  mouse,  but  some  instructions  would  help. 
The  mouse  implementation  Is  probably  the  biggest  benefit  of  hypertext. 

I  figured  out  that  on  a  3  button  mouse  the  left  key  =  FI  and  the  right 
key  =  ESC.  I  found  the  system  much  simpler  to  use  with  a  trackball. 
Through  some  experimentation,  I  discovered  that  If  I  clicked  on  the  top 
of  the  screen  the  F10  menu  would  appear.  Movement  was  much  quicker  with 
my  trackball.  The  only  time  I  was  unable  to  use  it  was  when  typing  was 
required. 

d.  A  manual  would  be  a  much  better  way  to  present  this  material 
even  If  problems  with  tutorial  help  are  fixed.  Definitely  need  manual. 
Need  to  define  what  hypertext  is.  The  terms  "link"  and  "icon"  as  used 


were  unfamiliar.  The  meaning  becomes  obvious  after  going  through  a  few 
windows,  however. 

e.  Liked  instructions  on  how  to  use  system  —  system  easy  enough 
to  use  so  that  much  instruction  isn’t  necessary,  but  it  is  nice  that  it 
is  available. 

f.  Control  panel  at  top  of  each  window  uses  nonstandard  applica¬ 
tions  of  standard  commands  (exit,  control  panel  help). 

g.  No  way  to  exit  the  system  from  cover  screen. 

3.  Display 

a.  Monochrome  monitor:  A  monochrome  monitor  was  distracting 
because  the  background  is  amber  with  black  blocks  surrounding  the 
letters.  Does  it  need  to  be  used  with  color?  I  have  a  mono-color 
monitor  and  I  found  the  darkened  spaces  between  words  distracting.  Is 
there  anyway  to  make  this  background  one  color  vice  the  blank  spaces?  I 
had  difficulty  with  the  appearance  of  the  text  on  my  screen.  The  text 
was  difficult  to  read  because  each  individual  word  was  reversed  high¬ 
lighted  from  the  background.  I  worked  the  system  on  CGA  and  changed  the 
colors  to  get  a  black  background  with  white  text  to  make  it  easier  to 
read. 


b.  Color  monitor:  Could  have  been  just  me,  but  even  though  the 
background  color  (blue)  and  the  white  text  looked  nice,  I  found  that 
when  there  was  a  fairly  full  page  of  material  the  text  seemed  crowded 
and  harder  to  read. 

c.  The  tours  screens  changed  too  quickly  for  me  to  read  them. 

Tours  function  was  too  slow. 

d.  Displays  should  have  more  fonts. 

4.  Depth/Breadth  of  System 

a.  The  reference  system  will  not,  I  don’t  think,  answer  questions 
about  what’s  inside  the  regulations. 

b.  A  very  useful  extension  would  be  to  have  the  actual  documents 
accessible  with  a  means  to  capture  pertinent  parts  of  them. 

c.  Data  and  depth  and  breadth  of  data  in  system  is  ok  for  cost 
analysis  refresher,  but  not  for  an  Instructor  ( 1 . e. ,  does  not  provide 
formulas  to  be  used  In  cost  analysis,  etc).  As  an  introduction  to  cost 
analysis,  your  program  as  it  stands  is  totally  acceptable,  but  could  be 
better  if  It  provided  more  detail.  More  links  also  need  to  exist. 

Links  needs  to  exist  between  terms  and  their  definitions.  This  is  a 
good  tool  as  is  for  people  with  experience  who  want  to  quickly  brush  up 
on  some  concepts  of  cost  analysis;  for  people  new  to  cost  analysis  there 
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needs  to  be  more  definitions;  and  for  people  to  perform  an  analysis 
using  only  this  tool  there  needs  to  be  a  little  more  detail. 

d.  Overall,  I  thought  the  system  worked  very  well  and  could  be  of 
benefit.  It  needs  to  be  expanded,  which  does  not  seem  to  be  a  small 
task.  Also,  it  may  be  difficult  to  keep  the  regulations  up  to  date  if 
you  intend  to  include  them. 

e.  I  think  the  system  has  merit.  You  might  want  to  break  the  EAs 

up  by  majcom.  Running  a  search  through  the  entire  USAF  database  could 
take  a  while  (provided  the  prototype  had  only  a  small  sample  in  it.  I 

know  I  would  make  good  use  of  such  a  system  if  I  were  a  base  level 

analyst. 

5.  Applications/Use 

a.  This  is  my  first  exposure  to  the  concept  of  hypertext  with  its 
range  of  capabilities.  The  concept  is  sound  and  as  you’ve  applied  it, 
it  obviously  has  strong  applicability  to  the  military. 

b.  I  think  this  system  could  be  used  effective  for  many  reference 
applications.  Putting  the  AFR  0-1  is  a  very  likely  application,  along 
with  adapting  the  system  to  a  specific  office  that  requires  a  great  deal 
of  reg  references  like  an  orderly  room  or  CBPO. 

c.  This  could  be  an  excellent  teaching  aid  as  well. 

d.  It’s  good  for  tasks  one  doesn’t  perform  on  a  regular  basis,  or 

those  tasks  that  are  complex  and  require  detailed  steps.  I  could  also 
see  a  use  for  this  as  a  training  aide. 

e.  Would  use  the  system  several  times  a  day  when  new  to  the 
program  but  only  once  or  twice  a  month  after  becoming  familiar  with  my 
job. 


f.  Overall,  the  system  would  be  very  useful!  Can  you  read  ASCII 
text  directly  in  and  create  the  links  after  the  text  is  there?  How  many 
levels  can  you  imbed  the  text  to?  Can  you  search  for  topics?  How  much 
does  it  cost?  Have  the  "glitches"  been  fixed  yet?  Who  makes  the 
software? 

6.  HyperWriter  system  unique  comments 

a.  Remembering  to  press  the  FI  Instead  of  enter  took  some  getting 
used  to. 


b.  Past  history  function  could  be  expanded. 

c.  Tabbing  beyond  last  selection  should  loop  back  to  first 
selection. 
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d.  Data  links  would  be  great  if  you  could  activate  them  with  the 
first  letter  of  the  word.  FI,  arrow,  tab,  and  esc  movement  were  good 
but  enabling  the  link  with  key  letters  would  be  nice  too. 

e.  Couldn’t  get  out  of  link  map.  Pushing  FI  to  activate  link 
caused  the  computer  to  lock  up  and  I  had  to  reboot.  There  were  several 
times  when  the  system  locked  up  on  me. 

f.  Map  is  hard  to  read  but  is  the  heart  of  the  system.  .  .  Come  up 
with  a  better  map!  Why  is  the  map  (flowchart)  sideways  anyhow?  What 
about  scrolling  [back  and  forth  as  opposed  to  up  and  down]?  Map 
function  does  not  serve  much  use  for  the  end  user. 

g.  I  found  it  annoying  that  the  screen  had  to  be  completely 
redrawn  every  time  you  selected  an  item. 
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